QTP Tutorials & Interview Questions

Enjoy the newly added section of Software Testing Glossary, Software Verification & Validation, Software Test Automation, Finest Software Testing Links

Recommended Software Testing, Test Automation & VBScript Books.

Mercury is the world leader in application delivery, with 58.8-percent market share in automated software quality and performance testing products.
QuickTest Professional is most suitable Automation Software Testing Tool in this fast changing software development world.
Mercury QuickTest Professional : provides the industry's best solution for functional test and regression test automation - addressing every major software application and environment.
Points worth noticing about QTP (QuickTest Professional):

As QTP (QuickTest Professional) is relatively easy to use, an organization has to spend minimal time, money and effort in training its employees on QTP.
QTP allows you to do regression testing with ease on repeatedly changing applications and environments.
QTP allows sharing automated testing assets, functions, and objecting repositories enabling an organization to deliver quality products and services, and improve revenues and profitability.
QTP can be integrated with WinRunner, LoadRunner, and TestDirector.

Please keep visiting this Blog as I will be updating and expanding it at regular intervals. If you have any comments/suggestions please email me at dhall.sachin@gmail.com

Test Case Templates

noreply@blogger.com (sachin) — Sat, 12 Mar 2016 15:41:00 +0000

Test Case Templates

Have a look at below test case templates from around the web:
1. Internal Test Cases Template
2. Test Case Template
3. Looking for an excellent example of using a spreadsheet for test case management
4. Download Sample Test Case Template with Explanation of Important Fields
5. Sample Test Case Template with Examples [Download]
6. Test Case Template and Examples
7. Test Case and Its Sample Template
8. 8 Useful Test Case Templates to Download for Free
9. Test Case Template
10. Test Case Template
11. Test Case Template for Mobile App Testing in Startups
12. Test Case Template
13. Test Case Template
14. sample test case template excel
15. TEST CASES AND TEMPLATE INTRODUCTION WITH EXAMPLE
16. Creating Test Cases in Excel

Install UFT / QTP 12-5

noreply@blogger.com (sachin) — Sun, 13 Sep 2015 14:11:00 +0000

Install UFT / QTP 12.5

1. As discussed in the post [Download UFT / QTP 12.5], I downloaded the full installation package and unzipped it. After unzipping the download, you get the following list of files and folders. Double click on “setup”.

2. Click on "Unified Functional Testing Setup":

3. The following window opens, where prerequisite programs are installed (including .Net Framework 4.5). Click ok.

4. After prerequisite programs are installed successfully, the setup wizard opens. Click Next.

5. Accept the license agreement and click Next.

6. Choose the features to be installed. LeanFT is, by default, not installed. You can install it if you want. Click Next.

7. Set IE configurations etc and click Next.

8. Installation starts.

9. Click Finish when installation is done.

10. Launch QTP / UFT 12.50.

11. Add-in Manager is shown. Click ok.

12. QTP / UFT 12.50 is launched. Go to Help (menu) and check the version.

Download UFT / QTP 12.5

noreply@blogger.com (sachin) — Mon, 07 Sep 2015 15:15:00 +0000

Download UFT / QTP 12.5

1. Go here.

2. Click on Download Now link.

3. You will be redirected to below page.

4. You can Sign Up or Sign In (if you already have an account). I created a new account and signed in.

5. On clicking 'Sign In' (above), below screen opens. Click 'Next' in below screen.

6. Click 'Go To MyAccount'.

7. Click on Download.

8. You can download a full installation package or a compressed package.

9. I downloaded the full installation package. It's around 2 GB.

Interview Questions for QA Lead / Manager

noreply@blogger.com (sachin) — Sat, 22 Aug 2015 17:23:00 +0000

Interview Questions for QA Lead / Manager

QA Lead / Manager interview questions will surely give you the feel of what to ask during interview. These questions are just the starting point and may go a long way in conducting successful interviews and hiring correct candidates. For answers to these QA Lead / Manager interview questions, please go to the respective site link given at the end of each set of questions:

Q. Let’s say you are the first QA manager joining our startup. What are the first three things you would do?
Q. What’s your definition of a good testcase? Can you give me an example?
Q. Let’s say you have a testplan with over 200 testcases. How do you decide what should be automated and what should still be done manually?
Q. How do you determine which devices and OS versions we should test on?
Q. What automation frameworks do you have experience with and and what are their pros and cons?
Q. What are the most important considerations for leveraging mobile test automation effectively?
Q. To what extent should developers do their own testing or do you believe testing is the responsibility of the QA team?
Q. What’s your experience using Continuous Integration as part of the development process?
Q. What are some of the challenges in mobile app testing?
Q. How do you best manage manual and automated testing working together?
Q. How do you think acceptance testing should be implemented in the development process?
[Source: 11 interview questions for QA managers]

Q. Customer has reported severe defects in Daily balance report. The customer is unhappy that the problem is not fixed even after a week. What action you as a PM will take to restore confidence of customer and ensure that this will not happen in future?
Q. It’s observed that the testers in your organization are performing tests on the deliverable even after significant defects have been found. This has resulted in unnecessary testing of little value because re-testing needs to be done after defects have been rectified. You are the test manager and going to update the test plan with recommendations on when to stop testing. List the recommendations you are going to make.
Q. You are newly appointed as a test lead in an organization which uses manual testing. Your boss wants you to put forth three testing tools and their features to create awareness about the testing tools in the top management. Suggest any three testing tools for your test Environment and why do you suggest them?
Q. You are working on a project, where the requirements change dynamically. The data in the project comes from various ends (from various Platforms) and are inter-dependent. You see this as a big risk in the project. How would you plan accordingly?
[Source: Software testing interview questions Test manager Part I]

Q. How do you interact with your team members? (looking for staff meetings, status reports, 1:1 sessions, open door policy, etc.)
Q. What are your expectations of your team? What is the most important characteristic of a successful software engineer?
[Source: How to interview a QA Manager or Director?]

Q. I’ll give you a software to test next Monday. You will have to finish test activities to release it on Friday. I'll ask you next Wednesday how is your progress. How would you manage to give me appropriate information?
[Source: What type of questions should be asked if I am taking an an interview of QA / Testing Lead]

Q. Describe a typical work week for QA lead position?
Q. Why should we hire you as a QA lead?
Q. Why do you want to work with us?
[Source: QA lead interview questions]

Q. Which one do you rate higher - compensation or work environment?
Q. What are the qualities in you which are criticised most by your managers?
Q. Your team member is muslim and takes time off to offer Namaz during critical project schedule? How would you handle that situation?
Q. How well do you work under stress?
Q. How do you manage underperforming resources?
Q. Is your BOSS always correct?
Q. What do you hate about your boss?
Q. What do you like about your boss?
[Source: Book: Job Interview By R.A. Padmanabha Rao]

Q. When do you stop testing?
Q. How will you prepare your team for session based testing?
Q. When will you prepare a test plan if requirements are in progress?
Q. What is strategy you follow to decide whether the product can be tested manually or automatically?
Q. How will you maintain sprint log for test execution in agile?
Q. What is meant by defect leverage ratio how it will be used?
Q. How will you calculate field fault density?
Q. When will you classify and work on a defect with status as high severity and low priority, low severity and high priority?
Q. What are the steps do you take to get organization context to bring testing into the development process.
Q. Which is the artifact you feel contributed most during testing and which is the least, why?
[Source: Test Lead Interview Questions]

Q. As a team lead how do you pacify an angry client?
Q. What are the attributes a team leader must look for while selecting members for their team?
Q. What are the Core skills needed for Team Lead?
Q. How does a team lead identify performance problems and solve the same among their team members?
Q. What steps must a team leader take to motivate the team?
Q. What are the communication methods you followed within team and to client ?
Q. What are the weakest qualities or attributes a team leader should avoid definitely?
Q. If conflict arrises between two people how will solve that. If one person is overlooking into others job how to deal with such type of people?
[Source: Team Lead Interview Questions]

Q. What were your roles and responsibilities and how was your time divided between tasks in a project?
Q. What QA process do you use in your project and why?
Q. What do you consider to be your key accomplishments/initiatives?
Q. Have you been involved in test estimation and how do you do it?
Q. What tools do you use and why?
Q. Process familiarity and Mastery – if you process you follow at your work place is waterfall, onsite-offshore, Agile or anything to that effect, expect detailed Q&A about its implementation, success, metrics, best practices and challenges among other things.
[Source: 6 Most Common QA Test Lead/Manager Interview Questions (with Answers and our Tips)]

Q. What do you think are the five notable characteristics of a great QA resource?

Explain Function Point Analysis (FPA)?

noreply@blogger.com (Unknown) — Wed, 19 Aug 2015 17:24:00 +0000

Function Point Analysis

Function points are a unit of measure representing the functional size of a software application. The size is determined by identify the components of the system as seen by the end-user:

Inputs,
Outputs,
Inquiries,
Interfaces to other systems, and
Logical internal files.

Function points counting usually occurs when a developer wants to size and estimate development time and effort for an application or a project.

The components may be classified as simple, average, or complex. All of these values are then scored and the total is expressed in Unadjusted Function Points (UFPs).

Complexity factors described by 14 general systems characteristics, such as Data Communications, Distributed Data Processing, Operational Ease, Reusability etc can be used to weight the UFP. Factors are also weighted on a scale of 0 - not present, 1 - minor influence, to 5 - strong influence. The result of these computations is a number that correlates to system size.

Interesting resources on Function Points:

1. Function Point Analysis, Five Components of Function Points, An Approach to Counting Function Points, Benefits of Function Point Analysis.

FP Intro

2. Objectives of Function Point Analysis, An Overview of Function Point Analysis, The Five Major Components, Rating and Ranking the Components, Unadjusted Function Points.

An Overview of Function Point Analysis

3. What is Function Point Analysis (FPA)?, How is Function Point Analysis done?, Example of Function Point Analysis etc.

FPA PPT

4. Explain Function Point Analysis, Objectives, Characteristic of Quality Function Point Analysis etc.

FPA Fund

5. Software Estimation using Function Point Analysis: Difficulties and Research Challenges.

FPA

6. Controlling Project Scope with Function Point Analysis.

Scope & Function Point Analysis

7. Function Point Analysis, Objectives of Function Point Analysis, Problems with Function Point Analysis, Examples of Function Point Analysis, FPA components etc.

FPA

8. Requirements issues abound in system development despite many models and methods intended to verify that requirements are complete. This article highlights how function point analysis (FPA), the software sizing technique, delivers value as a structured requirements review.

Applying Function Points

9. An Introduction To Function Point Analysis.

Introduction To FPA

10. Effective Function Point counting depends on more than descriptions of externally observable results. Using Wilber's four-quadrant model, the document attempts to outline how the personal, social and cultural dimensions contribute to the outcomes.

The Psychology of Function Point Counting

11. Forgotten Aspects of Function Point Analysis.

Function Points Forgotten Aspects

12. How does FPA work?

13. Function Points: Their Use in Software Development and Maintenance.

14. Wikipedia - FPA.

Also See:
Function Point Analysis calculation templates

Load Testing Tools

noreply@blogger.com (sachin) — Thu, 13 Aug 2015 06:42:00 +0000

Load Testing Tools

Load testing is the process of putting demand on a system or device and measuring its response. Load testing is performed to determine a system’s behavior under both normal and anticipated peak load conditions. [Wikipedia]

Below you can find 6 Load testing tools, their features, price and link to download the trial versions.

1. Load Impact

Features of Load Impact:
1. With Loadimpact's large scale load tests you can use upto 50,000 simulated users in a single test.
2. You can use multiple user scenarios emulating different user types in a single test and get individual measurements for each type.
3. You can get geographic distribution of load so that load is generated from multiple geographical locations.
4. With Loadimpact's real-time testing you can watch and control your load test in real time. You can view results as they are coming in, live. Your graphs are updated dynamically throughout the load test.

You can learn more about Load Impact here.

Load Impact's plans start from free, then $60 and go up to $6000 depending on the usage. For more on pricing of Load Impact see here.

2. Browser Mob's Website Load Testing

Features of BrowserMob:
1. BrowserMob uses real browsers for website load testing which requires less scripting, no rewriting and an experience that more accurately mimics the real user load test experience.
2. BrowserMob lets you choose between Virtual Users, Real Browser Users, or a combination of both based on your website load testing needs.
3. BrowserMob's Website Load Testing services generate massive amounts of simulated website traffic from a huge pool of IP addresses - more than any other provider - at the best possible price.
4. All BrowserMob website load testing and website monitoring customers get exclusive access to their world class support staff to ensure a quality customer experience.
5. With convenient and customizable pricing options, customers can choose the load test service that fits their website load testing needs including a basic free service and the option to upgrade when needed.

For more on features of BrowserMob see here.

You can also sign up for a free trial.

Pricing starts from free to Pro. Basic is $499/week for 100 real browsers and 500 virtual users. For more on pricing of BrowserMob see here.

3. CloudTest Performance Testing Tool

Features of CloudTest Performance Testing Tool:
1. CloudTest’s patented visual test environment supports the creation of very complex tests – without programming – in hours.
2. Load servers are dynamically provisioned inside the firewall or on the cloud for fast test execution at any scale from any location.
3. Real-time analytics help identify and resolve issues while tests are running.
4. Performance and monitoring metrics are aggregated and correlated on a single time line with drill-down for inspection at any level of detail.
5. Tests can be paused or stopped the instant an issue is found and re-started once it is resolved.
6. It’s easy for developers to create and run low-scale performance tests and incorporate tests, test execution, and test results into continuous integration servers like Hudson and Jenkins.
7. As tests grow in complexity and scale, QA can use internal lab resources to generate load.

For more features of CloudTest Performance Testing Tool see here.

You can also sign up for a free trial.
If you want to see CloudTest in action, you can take a look at demo.

Use below email addresses for more info on CloudTest:
info@soasta.com or emeainfo@soasta.com

4. Keynote's Web Load Testing

Keynote has 2 products under web load testing: Test Perspective and LoadPro

Keynote Test Perspective is a cost-effective, completely self-service Web site load testing tool. With Test Perspective you can run the most realistic load tests on-demand and receive immediate feedback on modifications you make to your Web site.

Keynote LoadPro is a turnkey Web load testing service. Their expert consultants test your site with real-world Internet traffic and uncover performance problems long before they impact your business.

Test Perspective Features:
1. Test Perspective utilizes their global test and measurement network that includes load-generating agents from multiple geographic locations and Internet backbones. Simply get a Test Perspective subscription, let them know how many virtual users and hours you want, test your Web application at the traffic levels you desire.
2. Set up your first load testing trial in less than 15 minutes. Your account includes sample scripts which are ready to run right out of the box. No configuration files to edit, no calculations to perform, just follow the simple guided workflow and launch immediately or schedule to launch at a later time.
3. View all the live load testing indicators on a single screen. Easily configure the screen for large displays or laptops. Watch in real time as virtual users expose symptoms of system overload.

For more on Test Perspective features see here.

LoadPro Features:
1. Scaling up to one million concurrent users from multiple Internet backbones and countries makes LoadPro the world’s most powerful load testing service.
2. Delivers the only load-testing service which factors in both the dynamic behavior of end-users as well as the unpredictable nature of the Internet.
3. Avoids the unnecessary capital expenditures of additional servers, databases, and bandwidth by accurately determining when these investments are absolutely necessary.

For more on LoadPro Features see here.

Get free trial of Test Perspective here.

For a free trial of LoadPro get in touch with their representative here.

For purchasing these tools contact Keynote here.

5. Monitis web LoadTester

Features of Monitis web LoadTester:
1. It monitors tons and tons of your data. External end-to-end monitoring, server and network monitoring, transactions monitoring etc.
2. You will have -Instant Failure Alerts - Live-Voice, E-mail, IM(Yahoo, GoogleTalk, ICQ), SMS, Twitter.
3. Monitis Mobile - mobile access for iPhone, Anroid, Symbian, Blackberry and Windows Mobile smartphones.
4. History - option of digging into historical data.

For more features of Monitis web LoadTester see here.

You can get a free trial of Monitis web LoadTester here.

Different pricing plans are there, starting from free to $383 per year. Go here for more on pricing of Monitis web LoadTester.

6. LoadStorm

Features of LoadStorm:
1. LoadStorm has a simple browser user interface. It's easy to create many scenarios representing different user types and allocate the right volume to each. It has thousands of servers at your disposal all around the world.
2. LoadStorm uses cloud infrastructure to provide you with up to 13,000+ requests per second. No servers to buy, no software license fee, no maintenance fee, no configuration of the load generators, and no download or install.
3. LoadStorm reporting includes:
Real-time graphs with performance metrics updated in one-minute intervals

Average Response Time.
Error Rate.
Requests per Second.
Throughput in KB/second.
Peak Response Time.
Concurrent Users.

More features or FAQs for LoadStorm.

You can also try it for free.

Pricing of LoadStorm varies between free to $9995 per month. For more on pricing see here.

Difference between Test Plan and Test Strategy

noreply@blogger.com (sachin) — Sun, 09 Aug 2015 15:03:00 +0000

Difference between Test Plan and Test Strategy

Test Plan	Test Strategy
Test Planning is done to identify possible issues and dependencies, to bring risks to surface so that they can be addressed. The test plan is the set of ideas that guide or represent the test process.	Test Strategy is a long term plan of action. If you want to document your overall test approach to projects, you take this information and put it in a document that does not change much over time. You can extract information which is not project specific and put it into Test approach or Test Strategy document.
Some of the Test Plan contents: test plan identifier, introduction, test items, features to be tested, features not to be tested, approach, item pass/fail criteria, suspension criteria and resumption requirements, test deliverables, testing tasks, environmental needs, responsibilities, staffing and training needs, schedule, risks and contingencies and approvals.	Some of the Test strategy contents: testing objective, methods of testing new functions, total time and resources required for the project, the testing environment, test strategies (approach) describe how the product risks of the stakeholders are mitigated at the test-level, which types of test are to be performed and which entry and exit criteria apply.
An example of Test Plan document: TEST PLAN OUTLINE (IEEE 829 FORMAT).	An example of Test Strategy document: TEST STRATEGY DOCUMENT.

Other good links on difference between Test Plan and Test Strategy:
1. You can go through the post: A Question About Test Strategy by James Bach.
2. Test Strategy: What is it?, What does it look like? [Link]

Sources:
1. Test Strategy.
2. Test Plan.
3. Agile Testing: A Practical Guide For Testers And Agile Teams By Crispin.
4. Lessons Learned in Software Testing: A Context-Driven Approach By Cem Kaner, James Bach, Bret Pettichord.

Also See:
Software Test Plan
Test Strategy

Reliability Testing

noreply@blogger.com (sachin) — Sun, 02 Aug 2015 13:25:00 +0000

Reliability Testing

Reliability testing is done to evaluate the product's ability to perform its required functions under stated conditions for a specified period of time or for a large number of iterations. Examples of Reliability include querying a data base continuously for 48 hours and performing login operations 10,000 times. [Source:Software Testing: Principles and Practice By Srinivasan Desikan, Gopalaswamy Ramesh]

Software reliability refers to the probability of failure-free operation of a system. It is related to many aspects of software, including the testing process. Directly estimating software reliability by quantifying its related factors can be difficult. Testing is an effective sampling method to measure software reliability. Guided by the operational profile, software testing (usually black-box testing) can be used to obtain failure data, and an estimation model can be further used to analyze the data to estimate the present reliability and predict future reliability. Therefore, based on the estimation, the developers can decide whether to release the software, and the users can decide whether to adopt and use the software. Risk of using software can also be assessed based on reliability information. [Hamlet94] advocates that the primary goal of testing should be to measure the dependability of tested software. [Source]

Testing for Reliability

Testing for reliability is about exercising an application so that failures are discovered and removed before the system is deployed. Because the different combinations of alternate pathways through an application are high, it is unlikely that you can find all potential failures in a complex application. However, you can test the most likely scenarios under normal usage conditions and validate that the application provides the expected service. As time permits, you can apply more complicated tests to reveal subtler defects.

This post contains a selection of testing concepts and recommendations that are especially relevant to creating reliable applications.

SCRUM Cheat Sheets

noreply@blogger.com (sachin) — Sun, 02 Aug 2015 12:49:00 +0000

SCRUM Cheat Sheets

Below are 5 most useful SCRUM cheat sheets for your use:

Scrum Cheat Sheet - 1
This SCRUM cheat sheet contains Scrum Roles, Scrum Process Diagram, Scrum Tools, Scrum Artifacts, Scrum Meetings, Scrum Estimations, Scrum FAQs.

Scrum Cheat Sheet - 2
This SCRUM cheat sheet contains Scrum Product Owner, Sprint Planning, Product Backlog, Scrum Master, Daily Scrum, Burndown Chart, Team Member, Retrospective, Sprint Backlog.

Scrum Cheat Sheet - 3
This SCRUM cheat sheet contains Scrum Basics, Scrum Roles, Scrum Activities, Scrum Artifacts, Scrum Extensions, Scrum Background, Scrum Diagram, Scrum Example.

Scrum Cheat Sheet - 4
This SCRUM cheat sheet contains About Scrum, Scrum Roles, Scrum Meetings, Scrum Artifacts, Scaling, Scrum Related Practices etc.

Scrum Cheat Sheet - 5
This SCRUM cheat sheet contains Elements of Scrum(Scrum Product Owner, Team Members, Scrum Master, Sprints etc.) and useful Glossary of Scrum.

Cross Browser Compatibility Testing

noreply@blogger.com (sachin) — Mon, 27 Jul 2015 04:06:00 +0000

Cross Browser Compatibility Testing

Cross browser testing is a type of compatibility testing designed to ensure that a web application behaves correctly (sometimes identically) in several different browsers and/or browser versions.[Source]

Cross Browser Testing Tools:

1. Adobe Browser Lab
You can have it's complete set of feature list here and other FAQs on subscriptions and access here.

2. Browsershots
Browsershots makes screenshots of your web design on different operating systems and browsers. It is a free open-source online web application providing developers a convenient way to test their website's browser compatibility in one place. When you submit your web address, it will be added to the job queue. A number of distributed computers will open your website in their browser. Then they will make screenshots and upload them to their central dedicated servers for review.
If you want to contribute and go for priority processing see here.

3. SuperPreview
SuperPreview was built to simplify the process of testing and debugging layout issues across different web browsers and platforms. You can view your pages in multiple browsers simultaneously or view how a page renders in a browser and compare it to a comp or mock-up image of a page.
SuperPreview was designed to integrate well with Expression Web. SuperPreview will be included as part of a future version of Expression Web. The final feature set and its availability have not been announced.
You can download the beta version for IE from here.

4. LitmusApp: Browser-Testing
You can see all its features and pricing.

5. Crossbrowsertesting
It has a free trial limited to 1 hour usage, 1 per person.
See other FAQs on crossbrowsertesting and "testing configurations" for Cross Browser Compatibility here. For other plans and cost see here.

6. Spoon
It requires a plug-in download. Spoon enables users to launch desktop applications from the web with no install, so you can test and use applications instantly, wherever you are. Know more about spoon here. Also see other FAQs on Spoon.

7. Browsrcamp
See all of the Browsrcamp's features here and the plans starts from 15 €/month for 150 minutes of testing. Usage is calculated to the minute.

8. Netmechanic
Browser Photo lets you see how your pages look on different browsers and operating systems. You can see all its features here and find the complete tutorial here.

9. Browsera
Browsera tests and reports cross-browser layout differences and scripting errors on your site. See all features of Browsera. Get all Plans & Pricing here.

10. BrowserSeal
BrowserSeal is a fast and easy to use cross browser testing and screenshot tool. It allows you to capture an image of your web site under multiple browsers with a single click of a mouse and instantly inspect the differences. It supports Internet Explorer (IE6, IE7 and IE8), Firefox (3.0 and 3.5), Google Chrome, Opera (8, 9 and 10) and Safari (3 and 4). Starting from version 2.0 BrowserSeal supports mobile browser testing with Opera Mini 5.1. It is heavily optimized for speed, which is especially evident on large web pages with scrollbars.
You can get a free download here.
See all FAQs here or if you want to buy it, go here.

11. Cloud Testing: Cross Browser Testing
The Cross Browser Testing feature of Cloud Testing allows you to verify both the look and feel and the functionality of your e-commerce and transactional websites using IE, Firefox, Safari, Chrome, Opera.
For all its features see here and all plans & pricing here.

12. Mozilla - addons
This is a great tool for web developers, since you can easily see how your web page displayed in IE with just one click and then switch back to Firefox. It works with Firefox 3.0 - 3.6a1pre.
You can download it here.

13. Lunascape
Lunascape 6 ORION - Lunascape has the world's only Triple Engine technology and now adds support for Triple Add-on. You can have the best features, performance, and speed of, Windows Internet Explorer, Mozilla Firefox, Google Chrome, and Apple Safari all in one browser. Also available as portable. Get all its features here. You can also download it for free here.

14. SortSite
SortSite - Test for browser compatibility issues in the most common web browsers - Internet Explorer, Mozilla Firefox, Google Chrome, Apple Safari and Opera.
You can download the trial or buy it.

15. Multi-Browser Viewer
Multi-Browser Viewer is the leading Cross Browser Testing software.
You can see all its features here. You can download the trial or purchase it.

Converting Local Time to UTC/GMT Time

noreply@blogger.com (sachin) — Mon, 20 Jul 2015 07:26:00 +0000

A VBScript function to convert Local Time to UTC/GMT Time

Function Convert_to_GMT()
Dim var_offset
Dim WshShell
set WshShell = WScript.CreateObject("WScript.Shell")
var_offset, return value from ActiveTimeBias, is in minutes
var_offset = WshShell.RegRead("HKLM\System\CurrentControlSet\Control
\TimeZoneInformation\ActiveTimeBias")
Taking current date/time and adding to var_offset because UTC = local time + bias
Convert_to_GMT = DateAdd("n", var_offset, Now())
Msgbox (Convert_to_GMT)
End Function

Calling function
Convert_to_GMT()

Many people do get confuse between UTC and GMT. Actually UTC and GMT is one and the same thing [Link].
You can check whether this function is returning the correct value by visiting World Time Server.

Resume - How To

noreply@blogger.com (sachin) — Mon, 20 Jul 2015 07:20:00 +0000

Not only readers ask me questions related to QTP or Software testing, but I receive many emails now and then, in which readers ask me to help them with their resumes. So I thought of writing this post which gives general idea about how to write a resume or you can say tips on creating a resume. This post not only shows you tips on creating a resume but at the end you can look at some of the resume examples also.

Resume
Resume is used by people to show their background and skill sets. Mostly resumes are used to secure new employment.
Resume draws attention to your achievements/accomplishments to show a probable employer that you are qualified for the work you want.
Main idea of resume is to get you an interview.

A great resume doesn't just tell them what you have done but makes the same assertion that all good ads do: If you buy this product, you will get these specific, direct benefits. It presents you in the best light. It convinces the employer that you have what it takes to be successful in this new position or career.

Sections in a resume
Sections which people more or less include in a resume are Name& Address, Objective, Summary, Technical Skills, Experience, Education, Achievements/Certifications/Interests, and References etc. Other things like passport number, expected salary etc. may or may not be included. Expected salary can be a part of Cover Letter or email for example.

Name& Address: should be neat and clean, without any unnecessary information, easier for recruiters to read and should have a professional look and feel. There are people who use just simple name and there are others who write complete address along with name. Some include only email and phone number with name. Do add logos if you want. Below are few examples:

Objective: should be clear and straightforward, should not be confusing and noticeably state what you can offer and your aim/goal/intention. Make statement clear, concise, and to the point for example "I want to get a job." is a bad objective and "To attain an internship in the computer industry." is a weak one, but "To attain an internship in the computer industry working with database or network security." is good. Avoid being overly specific to single company like "To attain a position at 3M Pharmaceuticals working on …". Objectives from the company’s perspective are always good like "To attain a web application programming position where knowledge of Java and the Struts framework will add value to the overall development process." Below are few examples taken mainly to show different styles/formatting:

Summary: include this mainly if you have 3 or more page resume. It can be summary of your complete experience or summary of your skills or learning's from your experience depending on what you want to highlight more. See example below with more elaborated and less elaborated summary:

Technical Skills: just be truthful, not only with skill sets but with each and every word in resume. Better if you can tell your skill from a scale of 1 to 10. See examples below:

Experience: company name, little bit about company [optional], [just 2 to 3 lines would do], your responsibilities there, projects you worked on, your duties in certain order, dates [joining-leaving]. Be sure to not leave gaps. Highlight specific work experience. Highlight marketable skills. Below are few examples:

Education: year and marks/GPA score are good to show. Below are few examples:

Headers and Footers can include stuff like page numbers, name, logo [of certifications, membership companies etc.].

After above examples let’s have some general tips on creating resumes:
1. First impression is the last impression and people are mostly busy, so your resume needs to be presentable in 30 seconds or less. Put the hot stuff in the beginning, and all less exciting information afterward. Focus on whatever is strongest and most impressive. Put the most important information on the first line of a writing "block" or paragraph. The first line is read the most.

2. Each resume will be designed according to the specific employer's needs.

3. Be truthful with your scores, gaps (if any) in job experience or education etc.

4. Verify your resume n number of times to avoid any typographical errors. Errors in resume or resume's those filled with jargon, or that don't make sense are unacceptable. Proofread everything a hundred times and have one other person proofread it. Someone who got really good grades in English.

5. If you don't have the right qualifications, don't apply for the job. When the job listing says "summer intern," don't ask for a full time job. You're not going to get it and you're just going to waste your time. (It won't count against you in the future, of course, because your original application was deleted so quickly I'll have no memory of you when we do get a full time opening and you apply for it.)

6. While making resume "Perfection is necessary, and perfection is earned by mastering 2 things: consistency and specificity". Consistency in headlines, sub-headings, fonts, bullets, even colons & periods etc. is very important and should not be taken as lightly.

7. Consider: whether to include the information at all, placement in overall structure of the resume, location on the page itself or within a section, ordering of information, more impressive ways of phrasing the information, use of design elements (such as boldface to highlight, italics to minimize, ample surrounding space to draw the eye to certain things).

8. Try not to include anything on the resume that could turn the employer off, anything that is controversial (political, etc.) or could be taken in a negative light.

9. Spell out numbers under and including ten; use the numerical form for numbers over and including 11 (as a general rule), unless they are the first words in a sentence. Spell out abbreviations unless they are unquestionably obvious.

Some more resume tips & references
Huge list of tips for creating resume
Resume tips from a hiring manager
Tips on how to Get Your Résumé Read by Joel Spolsky
Another Resume tip for Joel
How to Write a Masterpiece of a Resume
Resume Tips

Resume Examples
A Good One Page Resume
Another 1 page resume example in word format
A green word format 3 page resume
Another 3 page word format resume with photo
One more 2 page resume for your help
How a 140-Character Twitter Resume Could Land Your Next Job

Few more awesome resume examples in PPT format

Pieces Of Me: My Visual Resume

My Visual Resume - Saad Ahmed Shaikh

Visual resume

Abi Jones : Visual Resume

Software Testing Metrics

noreply@blogger.com (sachin) — Mon, 13 Jul 2015 05:07:00 +0000

Software Testing Metrics

Below are few useful and commonly used Software Testing Metrics:

1. Defect Age & Defect Spoilage
2. Defect Seeding
3. Defect Removal Efficiency (DRE)
4. Defect Density
5. Test Effectiveness
6. Schedule Variance & Cost Variance
7. Effort Variance
8. Test Coverage
9. Cost of Quality
10. Defect Metrics

Testing in Agile

noreply@blogger.com (sachin) — Sun, 12 Jul 2015 17:10:00 +0000

Testing in Agile

This post contains:

1. Traditional style QA
2. Agile Approaches
3. An Agile Tester
4. Traditional vs. Agile
5. Role Testers Play
6. Testing & Testers on Agile Projects
7. Question: While a developer is coding a task, it is impossible for a tester to test it (it doesn't exist yet). What then is the role of a tester at this point.
8. Question: Is the tester now involved in unit testing? Is this done parallel to black box testing?
9. Question: What does the tester do during a sprint where primarily infrastructural changes have been made, that may only be testable in unit testing?
10. Specific Technical Skills For Agile Tester’s Toolkit

Traditional Style Quality Assurance

Agile approaches are changing the conversation about software development

An Agile Tester
A professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development.

Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers.
They’re willing to learn what customers do so that they can better understand the customers’ software requirements.

Traditional vs. Agile Testing

Traditional	Agile
In the phased approach diagram (see previous image), it is clear that testing happens at the end, right before release. The diagram is idealistic, because it gives the impression there is as much time for testing as there is for coding. In many projects, this is not the case. The testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.	Agile is iterative and incremental (see previous image). This means that the testers test each increment of coding as soon as it is finished. An iteration might be as short as one week, or as long as a month. The team builds and tests a little bit of code, making sure it works correctly, and then moves on to next piece that needs to be built. Programmers never get ahead of the testers, because a story is not “done” until it has been tested.
Tests are usually created from a requirements document.	Rather than creating tests from a requirements document that was created by business analysts before anyone ever thought of writing a line of code, someone will need to write tests that illustrate the requirements for each story days or hours before coding begins.

Traditional

Agile

In the phased approach diagram (see previous image), it is clear that testing happens at the end, right before release. The diagram is idealistic, because it gives the impression there is as much time for testing as there is for coding. In many projects, this is not the case. The testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.

Agile is iterative and incremental (see previous image). This means that the testers test each increment of coding as soon as it is finished. An iteration might be as short as one week, or as long as a month. The team builds and tests a little bit of code, making sure it works correctly, and then moves on to next piece that needs to be built. Programmers never get ahead of the testers, because a story is not “done” until it has been tested.

Tests are usually created from a requirements document.

Rather than creating tests from a requirements document that was created by business analysts before anyone ever thought of writing a line of code, someone will need to write tests that illustrate the requirements for each story days or hours before coding begins.

Role Testers Play
The role of the tester with agile methods is an area that has received increasing attention. Initially with a focus on unit testing and ‘acceptance’ testing it appeared the system tester did not have a role in agile.

As Cem Kaner put it:
‘The nature of the tester's role changes in iterative projects. We are no longer the high-profile victims, we are no longer the lonely advocates of quality, we are merely (!) competent service providers, collaborating with a group that wants to achieve high quality.’

Testing and Testers on Agile Projects
1. It comes as no surprise to testers that working software is not the same as code – the tester clearly needs to be involved in not only assessing the product, but in deciding how the product is to be assessed. However, with automated unit tests in the hands of the coders, and confirmation-focused acceptance testing driven by the customer, testers should be aware that they will not be the sole – or even the primary – owner of deciding what works, and what doesn’t.

2. Testers need to be able to interact directly with designers and coders to understand the technological imperatives and restrictions that affect the software and its unit tests.

3. Testing will be driven by what is important to a user, rather than to fulfill a procedural requirement. It is better to have communication between tester, customer and designer than to maintain independence of the test team. In practice, it is common to find large-scale automated unit testing on agile projects, to confirm that code works as expected. The product will be judged by the customer typically by manual, confirmatory tests, with close observation for undesirable behaviors. Testing by testers is often driven by the need to measure the system’s performance and to find surprises – tools are very much in evidence, but rigid test scripts and procedures do not give the requisite opportunity for discovery, diagnosis and exploitation.

4. Testers are key collaborators with the customer, and on some agile projects will take on much of the role of the customer in designing and executing confirmation-driven acceptance tests. However, although testers traditionally make good customer advocates, working closely with a customer is preferable to becoming a proxy. Test strategies which lean heavily on an unchanging set of requirements (for example: designing and coding tests to be bought together with code late in the project; prioritizing tests based on a fixed risk assessment; testing only what has been agreed in the contract; reporting bugs only against fixed requirements) may be considered to be fatally flawed in the light of this value. Iterative collaboration is favored over a negotiated bill of work.

While a developer is coding a task, it is impossible for a tester to test it (it doesn't exist yet). What then is the role of a tester at this point.
1. Testers can prepare their test plans, test cases, and automated tests for the user stories before (or while) they are implemented. This helps the team discover any inconsistency or ambiguity in the user stories even before the developers write any code.

2. The tester could be working with the customer to fine tune the stories in the sprint.

3. They can often be involved in designing the tests that the coder will write to perform TDD.

4. If the agile team is fairly advanced then the tester would normally be writing the ATDD (Acceptance Test Driven Development) tests. These could be in a tool such as Fitnesse or Robot Framework or they could be more advanced ruby tests or even some other programming language. Or in some cases, simple record and playback can often be beneficial for a small number of tests.

5. They would obviously be writing/planning some exploratory testing scenarios or ideas.

6. The tricky thing to comprehend sometimes for the team is that the story does not have to be complete in order to drop it to the test stack for testing. For example the coders could drop a screen with half of the fields planned on it. The tester could test this half whilst the other half is being coded and hence feedback in with early test results. Testing doesn't have to take place on "finished" stories.

Is the tester now involved in unit testing? Is this done parallel to black box testing?

Testers only test code that passes all of the automated unit, integration and acceptance tests, which are all written by the developers. This split may be different elsewhere, though; for example your testers could be writing automated acceptance tests.

What does the tester do during a sprint where primarily infrastructural changes have been made, that may only be testable in unit testing?
1. Tester’s workload will vary between sprints, but regression tests still need to be run on [if any] changes...

2. You may also find that having the testers spend the first couple of days of each sprint testing the tasks from the previous sprint may help, however it's better to get them to nail down the things that the developers are going to be working on by writing their test plans.

3. Ensure that project or sprint requirements are clear, measurable and testable. In an ideal world each requirement will have a fit criterion written down at this stage. Determine what information needs to be automatically logged to troubleshoot any defects.

4. Prepare a project specific test strategy and determine which QA steps are going to be required and at which project stages: integration, stress, compatibility, usability, performance, beta testing etc. Determine acceptable defect thresholds and work out classification system for defect severity, specify guidelines for defect reporting.

5. Specify, arrange and prepare test environment: test infrastructure and mock services as necessary; prepare test data; write scripts to quickly refresh test environment when necessary; establish processes for defect tracking, communication and resolution; prepare for recruitment or recruit users for beta, usability or acceptance testing. Write test scripts.

6. Ideally the tester would be working with the team and the customer (who by the way, is part of the team!) to define the planned stories and build in some good, detailed acceptance criteria. This is invaluable and can save loads of time later down the line. The tester could also be learning new automation techniques, planning test environments, helping to document the outcome of the planning.

Specific Technical Skills For Agile Tester’s Toolkit
1. Automation Skills

Learn how to evaluate and choose the right tools, so you can help your team create maintainable automated regression tests. You can free up time for essential testing activities such as exploratory testing.

2. Acceptance Test-driven Development
Communication skills and good domain understanding enable testers to help business experts give good examples of both desired and undesired system behavior. We can turn these examples into tests that help the programmers understand what code to write. This is called acceptance test-driven development, and it is a major step toward building quality into the code and preventing defects.

3. Learning Styles

We all have blind spots that may prevent us from learning or triggers where we shut down and don’t hear the message anymore. Keep your emotional “hot buttons” in mind and focus on what you can learn from instructors, material, or teammates to enhance your abilities. Mentors with different backgrounds or from other industries besides testing and software development might work best with your learning style. Don’t limit yourself to coaches, mentors, and instructors who work specifically in software testing.

4. Learning Resources Examples

References:
1. Stackexchange
2. Searchsoftwarequality
3. Kohl
4. mcbreen
5. newsweaver
6. Stackoverflow
7. LEARNING FOR AGILE TESTERS, Part 2 by Lisa Crispin and Janet Gregor, Better Software Magazine Sept/Oct 2011
8. AGILE TESTING A PRACTICAL GUIDE FOR TESTERS AND AGILE TEAMS by Lisa Crispin & Janet Gregory

Mobile Application Testing

noreply@blogger.com (sachin) — Wed, 01 Jul 2015 14:11:00 +0000

Frequently asked questions on Mobile Application Testing

What are mobile applications?

As per [A Practical Guide to Testing Wireless Smartphone Applications by Julian Harty] mobile applications can be classified as:

Client applications: These are split into two groups: native and portable:
- Native: Client applications are installed on a mobile device and run on that device.
- Portable applications are generally able to run with few changes across a wide range of phone models and manufacturers.

Messaging applications: Current messaging applications use SMS messages as the communications medium.

Browser applications: Also split into two groups: markup and AJAX applications. Browser applications are server based applications that can be accessed through a web browser via a URL from a mobile device.

What are the different types of mobile application testing?

a. Mobile functional / functionality testing
Functionality testing of a mobile application is a type of black box testing to ensure that the application functions according to business specifications.

b. Mobile usability testing
Mobile usability testing refers to the usability testing performed on mobile products running on mobile platforms. Usability testing involves testing products according to what end users experience.[Mobile Usability Testing]

Examples of tasks (both open ended and directed) for usability testing:
- Check the local weather forecast for tonight (Open ended task).
- Use the app "Flipboard" for the iphone to check the latest news. Set up the app to show the news topics that interest you (directed task).
[Mobile Usability By Jakob Nielsen, Raluca Budiu]

More on mobile usability testing:
Eight Lessons in Mobile Usability Testing
Usability Testing: Key for developing high quality mobile applications
Practical tips for Web and mobile usability tests
Mobile usability testing

c. Mobile performance testing
To determine if the program (mobile site / mobile application etc.) meets its performance requirements.

More on mobile performance testing:
Testing Performance of Mobile Apps - Part 1: How Fast Can Angry Birds Run?
How to conduct performance testing on mobile applications
5 keys for effective mobile performance testing
Recording and Performance testing Android applications with HP Loadrunner VuGen
Mobile Performance Testing
The Art of Application Performance Testing: From Strategy to Tools by Ian Molyneaux

d. Mobile security testing
There are three main targets for threats – information, identity, and availability. Keeping that information secure is vital. The consequences of a malicious third party gaining access to personal financial information, for example, could be disastrous and irreparable. With mobile devices gathering personal, often photographic, information about where the owner lives, works and spends his or her leisure time, the consequences of a mobile device getting into the wrong hands could be truly catastrophic. And with devices being used for work and leisure, the possibility of sensitive business information getting into the wrong hands could have much, much wider – and potentially massive – implications.

More on mobile security testing:
Taking Mobile Security to the Next Level
Android Application Security Testing Guide Part-1
Security Testing Guidelines for mobile Apps
Mobile Security Testing
White Paper - Mobile Payment Security

e. Mobile localization testing
Localization testing is about more than just translating words. Characters, formatting, colors, calls to action and more needs to be adjusted to fit the local culture, context and understanding. [Mobile Localization Testing]

More on mobile localization testing:
What to consider for mobile application localization
Mobile application software localization
Localization Testing in Mobile World

f. Mobile compatibility testing
This entails validating the application for different mobile devices, OS versions, screen sizes, and resolutions as per the requirements, checking if integration server changes, checking for the app isolation with other apps on the device. [Mobile Application Testing]

More on mobile compatibility testing:
Mobile App Compatibility Testing on Real Handsets
COMPATIBILITY TESTING

g. Mobile interrupt testing
Interrupt Testing- An application while functioning may face several interruptions like incoming calls or network coverage outage and recovery. The different types of interruptions are:

--Incoming and Outgoing SMS and MMS
--Incoming and Outgoing calls
--Incoming Notifications [Wikipedia ]

h. Mobile interoperability testing
Mobile Interoperability Testing (MIOT) verifies interoperability within a test bed that includes base stations and subscriber devices from multiple vendors. [Next Generation Mobile Communications Ecosystem: Technology Management for Mobile by Saad Z. Asif]

What are the best practices in mobile application testing?

Each company follows its own set of best practices for testing mobile applications. Some of the best practices are common while the others may differ. Best practices evolve over a period of time through experience.

Following are the examples of some of the best practices:

Functional testing
Functional testing is an important aspect when it comes to mobile app testing. Test the app as a "black box" and try to break it. Open every screen of the mobile app and change the position from portrait to landscape mode and back again as most errors are discovered this way. Choose a test automation tool that fits into the company strategy and infrastructure etc.

Non functional testing
Another important area of mobile testing is the non-functional requirements testing of a mobile app. As an example the key non-functional requirements to be tested in a mobile app are:

Usability tests, validating the battery drain, testing the apps memory usage, compare the performance levels between the released and the new version of the app, compatibility and localization testing for mobile apps etc.

Designing a good Mobile Application Defect-Tracking System
A good mobile defect-tracking system includes the following information about a typical device defect:
- Application build version information, language, and so on.
- Device configuration and state information, including device type, Android platform version, and important specs.
- Screen orientation, network state, sensor information. etc.

Managing Device Configurations
Device fragmentation is one of the biggest challenges the mobile tester faces. Android devices come in various form factors with different screens, platform versions, and underlying hardware. They come with a variety of input methods such as hardware buttons, keyboards, and touchscreens. QA personnel must have a detailed understanding of the functionality of each target device. Whenever possible, testers should test each device as it is used in the field, which might not be the device’s default configuration or language. One hundred percent testing coverage is impossible, so QA must develop priorities thoughtfully. Using AVD configurations, the emulator is also an effective tool for extending coverage to simulate devices and situations that would not be covered otherwise.

Above points are taken from Calsoft labs and Introduction to AndroidTM Application Development, Fourth Edition by Joseph Annuzzi, Jr., Lauren Darcey, Shane Conder.

Apart from the above best practices, you can have a look at the below links to have more information on best practices in mobile application testing.

Mobile App Testing – Challenges, Solutions and Best Practices
Best Practices in Mobile App Testing
Best Practices in Mobile Application Testing
10 Best Practices for Mobile App Testing
Top Best Practices for Successful Mobile Test Automation
Mobile Application Testing – Challenges & Best Practices
Mobile Test Automation – Best Practices

How can we maximize the testing coverage while testing mobile applications?

Validating builds and designing smoke tests
It can be helpful to institute a build acceptance test policy (also sometimes called build validation, smoke testing etc). These smoke tests are short and target the key functionality to determine if the build is good enough for more thorough testing to be completed. This is also an opportunity to quickly verify bug fixes expected to be in the build before a complete retesting cycle occurs.
This reduces the number of bad builds delivered to QA.

Testing on the emulator versus the device
Devices and the service contracts that generally come with them can be expensive. Your test team cannot be expected to set up test environments on every carrier or every country where your users use the application.
Some of the benefits of the emulator:
-- ability to simulate devices when they are not available or in short supply.
-- ability to be automated like any other desktop software.

Testing before devices are available using the emulator
When preproduction phones cannot be acquired, testers can do some functional testing using emulator configurations that attempt to closely match the target platform, lessening the risks for a compact testing cycle when these devices go live, allowing developers to release applications faster.
[The Android Developer's Collection (Collection) by James Steele, James Steele, Nelson To, Shane Conder, and Lauren Darcey, Nelson To, Shane Conder]

What are the challenges in mobile application testing?

a. Mobile devices are updated very frequently.
b. An app has to work on different environments and configurations.
c. Some platforms like android support large number of devices in terms of screen resolution, memory etc.

For more on challenges see below:
6 key challenges of mobile app testing
5 mobile testing challenges and solutions
Agile Testing - Mobile application testing challenges
Mobile Application Testing and Challenges
The Challenge of Testing Applications

What is the mobile application testing strategy?

A test strategy is an outline that describes the testing approach of the software development cycle. [Pragmatic Software Testing : Becoming an Effective and Efficient Test Professional 1st Edition]

The main components of a mobile application testing strategy include usability; performance; security; and functional and nonfunctional testing across multiple platforms, devices and browsers. A complete mobile testing strategy must also account for testing across differing network connection speeds and geographical locations, as well as address the use of Wi-Fi, 3G or 4G connections. Testing must confront such issues as screen resolution and brightness, CPU, memory and OS optimization. The mobile testing strategy must be geared to the architecture of the applications under test whether they are Web, mobile Web, native applications or hybrids. Finally, an organization must consider the test approach, primarily the use of emulators versus actual devices, or even real user monitoring. [SearchSoftwareQuality]

Further have a look at below links to know more about mobile application testing strategy
Mobile Application Testing
Managing your mobile test strategy
Mobile Application Testing
5 testing strategies for building successful mobile apps
QUICK AND EFFICIENT MOBILE TESTING STRATEGY
Selecting the Right Mobile Test Automation Strategy Challenges and Principle

Who are the main providers of cloud services for mobile testing?

The majority of cloud services for mobile testing serves as a "cloud of devices" and provides remote access to smartphones in the cloud in order to accomplish testing, in other words, provides device hosting. Such services usually aid mobile developers in using remote smartphones as real devices for manual testing (interactive testing through a web interface), recording of scripts, and automatic running of tests on a range of models. For instance, Perfecto Mobile service provides all of this functionality representing different modern hardware and software mobile platforms (Android, iOS, Windows Phone, and Symbian) and can be integrated with HP UFT (QTP) or MS Team Foundation Server. Devices available in the system have different parameters, for example, testing different types of Internet connections is possible. The service works with two kinds of test scripts: QTP and the Perfecto Mobile Application. Perfecto Mobile is only a public service, but UFT Mobile can also be deployed as a private cloud. UFT Mobile provides automated functional testing and special solutions for realistic mobile performance testing (e.g., LoadRunner and Performance Center).

Keynote DeviceAnywhere is a similar service that provides online manual and automated testing of a mobile app on a variety of devices. It can be integrated with existing ALM through HP QTP, IBM RQM or special Java APIs.

The SOASTA service provides two advanced solutions: TouchTest test automation for multi-touch, gesture-based applications and CloudTest for scalable mobile application testing (performance or load-testing with millions of geographically distributed emulated users). TouchTest scripts can be recorded and performed against user’s own device. Users can control test devices via IP addresses.

The Cigniti device cloud provides remote access to a variety of mobile devices via own proprietary mobile test automation framework, with test accelerators for test automation and performance testing. Cigniti is suitable for network carrier testing.

SeeTest by Experitest provides device cloud that can be deployed as a private platform within an organization. Test automation facilities include test script recording/performing on real devices or emulators and integration with HP UFT (QTP), TestComplete, C#, RFT, Java, Perl, Python. SeeTest also provides manual testing tools.

The CloudMonkey service runs MonkeyTalk scripts across many Android emulators and iOS simulators. Screenshot reports are positioned as the base testing results. CloudMonkey test jobs can be integrated with continuous integration (CI) servers like Jenkins.

The Appium on Sauce service covers two functionalities: iOS device hosting and easy CI. The latter means that it can be used as a build server and testers do not need to set up developer environment on local machines. Test automation is implemented with Selenium, and interactive testing is only possible for web mobile applications. Appium can be deployed privately.

The TestDroid Cloud is a device cloud service oriented towards Android apps testing that uses the TestDroid AppCrawler engine to verify application devices’ compatibility. TestDroid Recorder can be used to generate reusable Android JUnit test cases. Test results consist of screenshots and device logs. A tester can compare screenshots to check for GUI bugs. TestDroid can also be integrated with Jenkins or leveraged through REST APIs.

The Scirocco Cloud has all of the functionality of a device cloud, except of script recording. It supports only the Android platform and provides manual access to remote devices through its HTML5 web interface. Test automation is done by using one of three drivers: AndroidDriver, Monkeyrunner, or NativeDriver. Results are provided as a set of screenshots to compare.

The LessPainfull device cloud is oriented for Android and iOS apps testing. As a test automation engine, it uses Calabash for Cucumber and accepts Cucumber-based test scripts. LessPainfull provides two options: private cloud tailored for single customer and shared cloud with devices common for several customers.

TestQuest is a distributed framework for deployment within an organization. It is oriented towards Android application testing and can be integrated with MS Visual Studio.

The ZPX service provides device hosting and mobile test automation in the cloud and is compatible with HP ALM products.

Jamo provides a set of tools to perform remote and scheduled testing on a device. For instance, Wanconnector in combination with Remote Device Screen provides access to a device within different geographical locations. The M-eux Test tool supports web application testing.

Apkudo’s device analytics provide some elements of multidirectional testing by testing devices (e.g., new smartphone models) against the top 200 apps from the market. Similar services are available for smartphone hardware testing, but these have no relation to mobile apps like Datum that provides verification of calls, data quality, and video quality. Apkudo also offers free public and fully automated stress testing of the Android applications on the big range of models using the Monkey tool.

[Source: CLOUD PLATFORM FOR RESEARCH CROWDSOURCING IN MOBILE TESTING by Oleksii Starov]

Name some standalone tools for mobile application testing.

Android Debug Bridge
UI/Application Exerciser Monkey
Monkeyrunner
AndroidViewClient
Robotium

[Source: Dependability Problems of Complex Information Systems edited by Wojciech Zamojski, Jaroslaw Sugier]

Give some examples of mobile application testing tools.

Appium	iOS, Android	Open source
Calabash	iOS, Android	Open source
testdroid	iOS, Android	Pricing info
perfectomobile	They use real devices for iOS, Android and Blackberry. Here's a list of supported devices.	Pricing info
soasta	Device Clouds	Pricing info
Testin: The Leading Game Crash Solution		Sign up here for free demo
ubertesters	Android（version 2.2 and above）, iOS（version 5.1 and above)	Pricing info
Ranorex	iOS, Android	Pricing info
applause	iOS, Android, Windows 8	Pricing info

Some more mobile application testing tools.

Give the checklist for mobile application testing?

Soasta provides a good checklist as you can see below:

Mobile Specific Checklist:

Test Conditions
-Network
-Installation
-Performance
-Interrupt
-Device Integration

Interrupt Conditions
-Incoming/Outgoing Calls
-Popup Alerts (Calendar, Alarm, SMS, etc.)
-Power Cycle
-Extended Background

Installation Conditions
-Install
-Uninstall
-Reinstall
-Update

Network Conditions
-Network Type (Mobile variations and WiFi)
-Network Quality
-Network Loss
-Network Transition

Performance Conditions
-Speed / Responsiveness
-CPU and Memory Usage
-Battery Drain
-On-Device/ Memory Card Storage

For complete and different types of checklists please visit the below sites:
Checklist Mobile App Testing
The Mobile App Testing Checklist
Testing Checklist for Mobile Applications
Mobile App Testing Checklist
Mobile App Usability Checklist
Android iOS Application Security Testing Checklist
Are You Selecting the Best Tools for Mobile Software Testing? (Checklist)
iOS Application Security Testing Cheat Sheet
Mobile Testing Checklist
Mobile Testing Checklist
App Usability Testing Checklist
Mobile Application Development and Testing Checklist

QTP Tutorials Page 3

noreply@blogger.com (sachin) — Mon, 15 Jun 2015 17:01:00 +0000

QTP Tutorial 81 - File Content Checkpoint - Part 2

QTP Tutorial 82 - File Content Checkpoint

1 2 3

Difference between Walkthrough & Inspection

noreply@blogger.com (sachin) — Tue, 26 May 2015 14:55:00 +0000

Difference between Walkthrough & Inspection

Both Walkthroughs and Inspections are undertaken before actual development and hence they are conducted on documents such as development plan, SOW, RDD and SRS, Design document and broad WBS to examine their authenticity, completeness, correctness and accuracy.

Below are some of the major differences between Walkthrough and Inspection:

Walkthrough	Inspection
Walkthrough is less formal and has only few steps.	Inspections and reviews are more formal and logically sequential with many steps.
As discussed above walkthrough is less formal and quick.	Inspection is more formal, takes more time and is far more systematic due to the use of checklists.
A major difference between structured walkthroughs and inspection is that inspections collect information to improve the development and review processes themselves. In this sense, an inspection is more of a quality assurance technique than walkthrough.
In walkthrough, for example, you can call your colleague and do an informal walkthrough to just check if the documentation and coding is correct.	As far as inspection is concerned, for instance in your organisation, you can have an official body which approves design documents for any project. Every project in your organisation needs to go through an inspection which reviews your design documents. If there are issues in the design documents, then your project will get a NC (non-conformance) list. You cannot proceed without clearing the NC’s given by the inspection team.

Source:
SOFTWARE ENGG By JAWADEKAR.
Software Testing and Continuous Quality Improvement, Third Edition By William E. Lewis.
Software Testing By S. Koirala, S. Sheikh.

Entry / Exit Criteria in Software Testing

noreply@blogger.com (sachin) — Wed, 15 Apr 2015 16:07:00 +0000

Entry / Exit Criteria in Software Testing

Entry and exit criteria can be defined for testing as these can be defined for other phases in the life cycle of a software product.
Entry and exit criteria are a must for the success of any project. If you do not know where to start and where to finish then your goals are not clear.
The entry criteria are specific, measurable conditions that must be met before the process can be started. Similarly the exit criteria are specific, measurable conditions that must be met before the process can be completed.

[Source: The Certified Software Quality Engineer Handbook by Linda Westfall, Software Testing by S. Koirala, S. Sheikh]

Below are the examples of entry and exit criteria:

Example 1:

Exit criteria
- 100% statements, branch or decision coverage by the executed tests. This ensures a technical coverage and identifies the areas of the software that have not yet been executed.
- reaching a specific detection ratio for new defects per period of time, but this ratio must be function of the test effort and of the severity of the detected defects;
- the defects detected at this level correspond to the type of defects expected. This confirms the maturity level of the design and test processes preceding the current phase. This also enables us to determine the maturity of the tested product.
- all tests planned for this test level have been successfully executed.
- all tests for "catastrophic" and "critical" (or even "marginal") integrity levels have been designed, implemented and executed successfully on the last version of the software or system.

Some exit criteria that should be avoided:
Stopping testing when the planned test termination date is reached.
Stopping testing when the planned test effort has been reached.
Stopping when all the test cases have been executed without finding new defects.

Potential exit criteria for a system test level as provided by Rex Black:
No modification (design, code or characteristics) during the last 3 weeks, except to deal with the defects identified during system tests;
No stopping, crash, or inexplicable end of processes on any software servers or systems during the last 3 weeks;
No customer systems have become unstable or unusable following an installation failure during system testing;
The testing team has run all tests planned on the delivery candidate version of the software;
The development team has solved all the “to be fixed” defects, as planned by sales, marketing or customer services;

[Source: Fundamentals of Software Testing by Bernard Homès]

Example 2:

Entry criteria
Customer should provide requirements document or acceptance test plan.

Exit criteria
Customer has successfully executed the acceptance test plan.

[Source: Software Testing by S. Koirala, S. Sheikh]

Example 3:

Performance tests require a stable product due to its complexity and accuracy that is needed. Changes to the product affect performance numbers and may mean that the tests have to be repeated. It will be counter-productive to execute performance test cases before the product is stable or when changes are being made. Hence, the performance test execution normally starts after the product meets a set of criteria. The set of criteria to be met are defined well in advance and documented as part of the performance test plan. Similarly, a set of exit criteria is defined to conclude the results of performance tests.

[Source: Software Testing: Principles and Practice by Srinivasan Desikan, Gopalaswamy Ramesh]

Example 4:

Some of the entry criteria for system test may be:
Definition of all test scenario and test cases is completed.
Clarification of all queries is available.
Availability of hardware and software for initiating testing is ensured.
All review comments and unit testing defects are closed.
Installers are available if an application needs installations.
Installation testing, if applicable, is successful.
Smoke testing/ sanity testing is successful.

Some of the exit criteria may be defined as follows:
The number of defects found with respect to the targeted number of defects. If the target is achieved at the end of testing iterations, one may declare that testing is completed successfully.
Coverage in terms of requirements, functionalities and features is achieved as defined in the test plan.It needs completion of requirements traceability matrix with test results to declare adequate coverage.
Test cases defined in the test suite are completed.

[Source: Software Quality Assurance by Milind Limaye]

Example 5:

Few more examples of entry and exit criteria

[Source: Achieving Software Quality Through Teamwork by Isabel Evans]

Example 6:

Entry criteria
Are the necessary documentation, design and requirements information available that will allow testers to operate the system and judge correct behavior.
Is the system ready for delivery, in whatever form is appropriate for the test phase in questions?
Are the supporting utilities, accessories, and prerequisites available in forms that testers can use?
Is the system at the appropriate level of quality? Such a question usually implies that some or all of a previous test phase has been successfully completed, although it could refer to the extent to which code review issues have been handled. Passing a smoke test is another frequent measure of sufficient quality to enter a test phase.
Is the test environment - lab, hardware and system administration support - ready?

One exit criteria might be that that all the planned test cases and the regression tests have been run.

[Source: Managing the Testing Process: Practical Tools and Techniques for Managing by Rex Black]

Example 7:

Integration testing entry criteria:

Integration testing exit criteria:

System testing entry criteria:

System testing exit criteria:

[Source: Critical Testing Processes: Plan, Prepare, Perform, Perfect by Rex Black]

How to write a good bug report

noreply@blogger.com (sachin) — Sun, 15 Mar 2015 14:17:00 +0000

How to write a good bug report

It is always necessary to file a bug clearly so that the developer who fixes the bug can reproduce it with ease. In short a good bug report should be easy to understand and should not be confusing.

Points to consider while writing a bug:

1. Verify the problem you found is a new bug and NOT a duplicate.

2. Write precise and clear steps to reproduce the bug. A good bug report provides enough information to make the test easy to recreate.

3. Always include the expected behaviour.

4. Don't point out two or more issues in the same bug report. If you feel there appears another different issue when you follow the same steps, raise it separately, otherwise there is a chance that it get missed. In other words multiple bugs should not be grouped into one.

5. Don't disguise a feature request as a bug. You can't submit a bug report that says "This screen doesn't have a delete button". That's not a bug. "Well, it's not a correct screen. It doesn't have a delete button!" Okay, it's not a perfect screen. Why wasn't there a delete button in the original spec?

6. Attach logs in case of a crash / exception.

7. Try reading the bug report before hitting the submit button so as to check twice that everything you have written is correct and makes sense.

8. The quality of information in bug reports can crucially influence the resolution of a bug as well as its resolution time. Reports that contain all the necessary information can make resolving the bug somewhat easier.

9. Bug morphing is the phenomenon that occurs when a bug changes from one issue to a completely separate issue within the same bug report. Sometimes it happens quickly, and sometimes the morphing is drawn out over days or months. Regardless of the situation, bug morphing is never a good idea.
Bugs that have morphed are difficult to analyze for root cause. They also can cause confusion with product support or sustained engineering when they are reviewing product issues or searching to see if an issue a customer is seeing is caused by a known defect. If a bug begins to change in a bug report, it is crucial to stop and open a new bug for the new issue.

10. No bug is too trivial to report - small bugs may hide big bugs. Moreover clearly separate fact from speculation.

Also see:
a. Bug writing guidelines
b. Bug reporting guidelines
c. Balaji Kothandaraman
d. corsiKa♦
e. Making Software: What Really Works, and Why We Believe It By Andy Oram, Greg Wilson
f. Crystal Clear: A Human-Powered Methodology for Small Teams By Alistair Cockburn
g. How We Test Software at Microsoft By Alan Page, Ken Johnston, Bj Rollison
h. Managing Software Development By Samuel Menaker, Sheetal Guttigoli

Bug Report Template

noreply@blogger.com (sachin) — Fri, 13 Mar 2015 17:18:00 +0000

Bug Report Templates

Every good bug report needs exactly three things.
Steps to reproduce,
What you expected to see, and
What you saw instead. [Source]

Bug Report Templates

A simple bug reporting template which is easily modifiable according to the needs:

Below are few bug reporting templates from around the internet:
1. Bug Report Template by Kerry Forester
A generic software bug reporting template, with descriptions aimed at helping new testers submit good, useful reports.
2. Bug Report Template
3. DEFECT TRACKING LOG
4. Writing Better Defect Reports
Why do some testers get a much better response from development than others? Part of the answer lies in the defect report. Following a few simple rules can smooth the way for a much more productive environment. The objective is not to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. This paper focuses on two aspects of defect reports: 1) the remarks or description and 2) the abstract.
It includes a sample template also.
5. Bug Reporting Template
6. How to Prepare Better Test Report
It includes a sample bug report.
7. A very simple bug report template
8. Another simple bug report

What is SQL Injection?

noreply@blogger.com (Unknown) — Mon, 02 Feb 2015 18:48:00 +0000

Go to main post

Definition of SQL Injection

SQL injection takes place when an application processes user-provided data to build an SQL statement without validating or conforming the input and submits the statement to a database server for execution.

When successfully utilized, SQL injection allows an attacker to access back-end database content, remotely execute system commands and in some circumstances, take control of the server that is hosting the database.

SQL injection can occur in any part of an application and it is not restricted to Web applications. Any application that creates a database query based on user input is potentially susceptible to SQL injection. SQL injection attacks are not restricted to applications running against a particular database server. Oracle, SQL Server etc. are all potentially susceptible.

Below you can read more about:
1. SQL Injection examples,
2. Goal of SQL Injection,
3. SQL Injection vulnerabilities,
4. Testing SQL Injection,
5. Types of SQL Injection attacks,
6. SQL Injection mitigation and more.

Example 1 of SQL Injection

An example would be that if the SQL query looks like this:

SELECT FieldList FROM Table WHERE field = ‘userclause’;

Now, if the clause supplied by the attacker is “myclause’” (notice the trailing single quote), the SQL query now looks like this:

Select FieldList FROM Table WHERE field = ‘myclause’ ‘;

Typically, this will result in a syntax error because the trailing single quote will confuse the SQL server. Now, what if we try to change the nature of the WHERE clause by injecting a clause designed to always be true, such as “anything’ or ‘z’=’z”. Our query then becomes:

SELECT FieldList FROM Table WHERE field = ‘anything’ or ‘z’=’z’;

This version, because the conditions will always be met, will return all rows in the table.

The attacker can continue on from there with some guesses at table names and even get to where, instead of just copying or stealing the information in the database, the attacker is writing data to the database, if that is not forbidden. [Source]

Example 2 of SQL Injection

The following script shows a simple SQL injection. The script builds an SQL query by concatenating hard-coded strings together with a string entered by the user:

var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

The user is prompted to enter the name of a city. If she enters Redmond, the query assembled by the script looks similar to the following:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

However, assume that the user enters the following:

Redmond'; drop table OrdersTable--

In this case, the following query is assembled by the script:

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

The semicolon (;) denotes the end of one query and the start of another. The double hyphen (--) indicates that the rest of the current line is a comment and should be ignored. If the modified code is syntactically correct, it will be executed by the server. When SQL Server processes this statement, SQL Server will first select all records in OrdersTable where ShipCity is Redmond. Then, SQL Server will drop OrdersTable.

As long as injected SQL code is syntactically correct, tampering cannot be detected programmatically. [Source]

Here are few more examples on SQL Injection.

Goal of SQL Injection

The goal of an SQL injection attack is to attempt to manipulate queries or information sent to an SQL back end to gain control of the SQL server. This control can mean the ability to modify queries to get unauthorized information, but it can also go as far as modifying data on the server, invoking stored procedures, or even shutting down the SQL server, depending on the skill of the attacker and the level of control that can be gained.

Main goal of SQL Injection, in simple terms, is to bypass (get around) authorization and carry out data manipulation or read arbitrary data.

Successful SQL injection attacks can result in the attacker possibly being able to:

a. Run commands as the SQL Server user on the database server, using the xp_cmdshell extended stored procedure.

b. Run queries on linked servers.

c. Create new custom extended stored procedures to run explicit code with the SQL server process.

d. Use the “bulk insert” statement to read any file on the server.

e. Use bcp (Bulk Copy Program) to create arbitrary text files on the server etc. [Source]

SQL Injection Vulnerabilities

The attacker looks for vulnerability in a site or application before start of an SQL injection attack.

To test the vulnerability, the attacker often starts with what is the most common vulnerability: the single quote. In SQL, a single quote is the string literal delimiter. If user input is submitted directly to the SQL back end without sufficient validation or input “scrubbing,” it’s incredibly easy to gain control of the SQL server.

Unfortunately, error pages can reveal a lot of information about exactly what is happening behind the scenes. If you know what to look for, they’re a great tool to use when trying to diagnose and refine attack attempts.
The first thing to do is see just what error page is returned. If it’s an ODBC error page, the attacker knows right away that this is a true vulnerability because the error was generated from the SQL, which means the single quote inserted in the prior step was successful in passing from the front end to the SQL back end.

If an error page is returned that includes links, the attacker will search the links to see of they contain more details of the error. If a 302 Page Redirect is called, the attacker will try to capture the page it is redirected from; this may have more error details in it that can’t be easily read before the redirect occurs.
If a 500 Error Page is returned, the attacker knows that the injection may have been successful as this is the default error page for most Web servers. Though the attacker may not be able to determine much from this page, it will spur him on to greater attempts to exploit a possible weakness. [Source]

More on SQL Injection Vulnerabilities

1. SQL Injection Vulnerabilities Discovery
2. WordPress 2.3.1 SQL Injection Vulnerability
3. Vulnerabilities inside the database server
4. Understanding SQL Server Vulnerabilities
5. Testing For SQL Injection Vulnerabilities

Testing SQL Injection

Every parameter of every call must be tested separately to have a good picture of the Web service’s/site’s SQL injection vulnerabilities. Below is the list of Characters you need to test with:

Character Name	Unicode Value	Reason
Single quote/ Apostrophe (')	[U+0027]	SQL character used to escape strings. Remember to test all fields, not just string fields • Use alone • Use as the first character in otherwise valid input • Use in the middle of otherwise valid input • Use as the last character in a maximum length otherwise valid input• Use in places specific formatting is required after formatting requirements are met
Dash/hyphen(-)	[U+002D]	Use two as a SQL server single line comment indicator

For more on other Character Names and Reasons see here.

Black-Box Testing

For black-box testing, you need to use a browser and perform parameter tampering in any query or parameter you can locate on the site. The basic process is to replace the argument in every parameter on every script on the server with a test argument, one parameter at a time. Leave all the other parameters with valid data intact. Submit this parameter (or set of parameters) to the server, and then examine the returned page for the signs of possible vulnerabilities.

White-Box Testing

Determine if the Web site is performing any type of input validation. Strings tend to be more susceptible to parameter injection than other data types. One parameter at a time, replaces the argument of each parameter on each API, with each of the listed single-quote test scenario, and submits it. Then, examine the entire response from the server to see if you received an error and whether you can tell if it’s an SQL error.

Types of SQL Injection Attacks

1. Types of SQL Injection Attacks
2. SQL Injection Introduction, Categories of SQL Injection Attacks, SQL Injection Methods, What’s Vulnerable and What’s Not
3. Blind SQL Injection attacks explained
4. Some more SQL Injection Attack Types
5. SQL Injection Attacks And Their Ramifications
6. SQL Injection Attacks Explained

SQL Injection Mitigation

To start with, run all strings that come from users through a string checker looking for anything out of the ordinary. If you expect a string to contain only letters, numbers and spaces, then write a regular expression that verifies that and get in the habit of rejecting all input that doesn't conform. That should make it impossible for attackers to put special characters like quotation marks in there.

Assume that a clever attacker will subvert that. Assume that you've made a mistake and forgotten to put a check in somewhere. Look for every place in the code that uses that user-supplied string. Don't stop at SQL construction.
Anything that gets passed to JScript's eval could be an injection attack.
Anything that gets echoed back to the user could be a cross-site scripting attack. Anything that gets written to disk could be an attempt to write a script onto the server's disk to trick an admin into running it.
Eliminate as many of these as you can.

But how do you eliminate them? A great way to mitigate the risk of a SQL injection attack is to use stored procedures. Stored procedures ensure that only the query that you want to run actually runs. But they have nice properties in addition to being more secure against injection. They can be updated in the database, so that when the database structure changes, you change the stored procedure rather than searching through your code for SQL statement construction. And stored procedures often run faster because the database can optimize itself for them. [Source]

Use Parameterized Input with Stored Procedures

Stored procedures may be susceptible to SQL injection if they use unfiltered input. For example, the following code is vulnerable:

SqlDataAdapter myCommand = 
        new SqlDataAdapter("LoginStoredProcedure '" + 
                                     Login.Text + "'", conn);

If you use stored procedures, you should use parameters as their input.[Source]

Wrapping Parameters with QUOTENAME() and REPLACE()
In each selected stored procedure, verify that all variables that are used in dynamic Transact-SQL are handled correctly. Data that comes from the input parameters of the stored procedure or that is read from a table should be wrapped in QUOTENAME() or REPLACE(). Remember that the value of @variable that is passed to QUOTENAME() is of sysname, and has a maximum length of 128 characters.

@variable	Recommended wrapper
Name of a securable	QUOTENAME(@variable)
String of <= 128 characters	QUOTENAME(@variable, '''')
String of > 128 characters	REPLACE(@variable,'''', '''''')

When you use this technique, a SET statement can be revised as follows:

--Before:

SET @temp = N'select * from authors where au_lname='''

+ @au_lname + N''''

--After:

SET @temp = N'select * from authors where au_lname='''

+ REPLACE(@au_lname,'''','''''') + N''''

Injection Enabled by Data Truncation

Any dynamic Transact-SQL that is assigned to a variable will be truncated if it is larger than the buffer allocated for that variable. An attacker who is able to force statement truncation by passing unexpectedly long strings to a stored procedure can manipulate the result. For example, the stored procedure that is created by the following script is vulnerable to injection enabled by truncation.

CREATE PROCEDURE sp_MySetPassword

@loginname sysname,

@old sysname,

@new sysname

AS

-- Declare variable.

-- Note that the buffer here is only 200 characters long.

DECLARE @command varchar(200)

-- Construct the dynamic Transact-SQL.

-- In the following statement, we need a total of 154 characters

-- to set the password of 'sa'.

-- 26 for UPDATE statement, 16 for WHERE clause, 4 for 'sa', and 2 for

-- quotation marks surrounded by QUOTENAME(@loginname):

-- 200 – 26 – 16 – 4 – 2 = 154.

-- But because @new is declared as a sysname, this variable can only hold

-- 128 characters.

-- We can overcome this by passing some single quotation marks in @new.

SET @command= 'update Users set password=' + QUOTENAME(@new, '''') + ' where 

username=' + QUOTENAME(@loginname, '''') + ' AND password = ' + QUOTENAME(@old, '''')

-- Execute the command.

EXEC (@command)

GO

By passing 154 characters into a 128 character buffer, an attacker can set a new password for sa without knowing the old password.

EXEC sp_MySetPassword 'sa', 'dummy', 

'123456789012345678901234567890123456789012345678901234567890123456789012345678
901234567890123456789012''''''''''

'''''''''''''''''''''''''''''''''''''''''

For this reason, you should use a large buffer for a command variable or directly execute the dynamic Transact-SQL inside the EXECUTE statement.

Securing your database will greatly mitigate SQL injection hacks. By partitioning access and restricting capabilities via standard hardening techniques (such as removing unnecessary procedures), you will greatly reduce (or completely negate) what can be done with SQL Injection. Beware, though don't forget to harden the web application code as well or you could find other vulnerabilities slipping through. [Source]

Some More Mitigation Techniques:

1. unixwiz
2. SQL Injection Mitigation: Using Parameterized Queries
3. SQL Injection Mitigation: Using Parameterized Queries Part 2

Also See:
Cookie Testing
Cross Site Scripting

Write for a QTP Blog

noreply@blogger.com (sachin) — Wed, 07 Jan 2015 16:22:00 +0000

Write for us:

In case you are interested to write for qtp.blogspot.com, please get in touch with me via email (dhall dot sachin at gmail dot com) using subject "Guest Posts".

Topics for guest post include manual testing, automation, QTP/UFT etc. The article should be interesting. Not all articles sent will be published. It will depend on the quality of the written content and how interesting the topic is.

The article must be original and cannot be republished elsewhere on the web. Your articles may be edited prior to publishing.

Yes, you will be paid for the article. The amount of money for an article will depend on the length of the article and its quality. Be assured that you will be paid well for each accepted article.

Difference between Testing methods & Testing techniques

noreply@blogger.com (sachin) — Mon, 08 Dec 2014 16:41:00 +0000

Difference between Testing methods & Testing techniques

Testing methods and testing techniques are topics which confuse many testers even after couple of years of experience. So lets try to find out the exact difference between testing methods & testing techniques.

Broadly there are two different ways in which software can be tested, that is, there are two different methods to test software:
a. Black box testing
b. White box testing

These black box and white box testing methods further have testing techniques as can be seen below:

Testing techniques under black box testing method:
Boundary value analysis
Equivalence partitioning
Error guessing
Cause-effect graph
Decision table testing etc.

Testing techniques under white box testing method:
Path Testing
Branch testing
Statement coverage
Decision coverage etc.

Difference between Localization & Globalization Testing

noreply@blogger.com (sachin) — Wed, 19 Nov 2014 16:22:00 +0000

Difference between Localization & Globalization Testing

Globalization Testing	Localization Testing
Globalization is the process of designing and developing applications that function for multiple cultures.	Localization is the process of customizing your application for a given culture and locale.
Globalization addresses the business issues associated with taking a product global. In the globalization of high-tech products this involves integrating localization throughout a company, after proper internationalization and product design, as well as marketing, sales and support in the world market. Globalization is a term used in many different ways. For example there is a process of creating local or localized versions of web sites, which we will refer to as “web site globalization. web site globalization refers to enabling a web site to deal with non english speaking visitors i.e. internationalizing the site’s back-end software, designing a multi-lingual architecture and localizing the site’s static or dynamic content. "G11n" is often used as an abbreviation for globalization. "G11n" means that there are 11 characters between G and n in Globalization.	Localization involves taking a product and making it linguistically and culturally appropriate to the target locale (country/region and language) where it will be used and sold. A well-localized product enables users to interact with a software application in their native language. They should be able to read all interface components such as error messages or screen tips in their native language and enter information with all accented characters using the local keyboard layout. "L10n" is often used as an abbreviation for localization.
The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.	Localization translates the product UI and occasionally changes some initial settings to make it suitable for another region. Localization testing checks the quality of a product's localization for a particular target culture/locale. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product.

Source:
Globalization Testing.
Localization Testing.
ASP.NET Globalization and Localization.
A Practical Guide to Localization by Bert Esselink.
Software Testing by Wikipedians.
Software Testing: Principles and Practice by Srinivasan Desikan, Gopalaswamy Ramesh.