Happy Republic Day

जन  गण   मन   अधिनायक  जाया  हे

भारत  भाग्य  विधाता
पुनजब  सिंध  गुजरात  मराठा
द्रविदा  उत्कल  बंग
विन्ध्य  हिमाचल  यमुना  गंगा
उच्चाला  जलधि  तरंगा
तुभ  शुबहा  नामे  जगे
तुभ   शुबहा  आशीष  मांगे
गए    तुभ  जाया  गाथा
जन   गन  मंगलदायक  जय  हे
भारत  भाग्य  विधाता
जाये  हे  ! जाये  हे  ! जाये  हे  !
जाये ,जाये ,जाये ,जाये  हे  "

Test object model in QTP

The test object model is a large set of object types or classes that QuickTest uses to represent the objects in your application. Each test object class has a list of properties that can uniquely identify objects of that class and a set of relevant methods that QuickTest can record for it.

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

A run-time object is the actual object in your Web site or application on which methods are performed during the run session. When you perform an operation on your application while recording,

QuickTest:

➤ identifies the QuickTest test object class that represents the object on which you performed the operation and creates the appropriate test object

➤ reads the current value of the object's properties in your application and stores the list of properties and values with the test object

➤ chooses a unique name for the object, generally using the value of one of its prominent properties

➤ records the operation that you performed on the object using the appropriate QuickTest test object method

For example, suppose you click on a Find button with the following HTML

source code:

< type="submit" name="Find" value="Find">

QuickTest identifies the object that you clicked as a WebButton test object. It creates a WebButton object with the name Find, and records the following properties and values for the Find WebButton. It also records that you performed a Click method on the WebButton.

QuickTest displays your step in the Expert View like this:

Browser("Mercury Interactive").Page("Mercury Interactive").

WebButton("Find").Click

Steps to develop and run software tests

The following are some of the steps to consider:

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

Things to do when there isn't enough time for thorough testing

Use risk analysis, along with discussion with project stakeholders, to determine where testing should be focused.

Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:

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

Steps to be done after a bug is found

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

• Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.

• Bug identifier (number, ID, etc.)

• Current bug status (e.g., 'Released for Retest', 'New', etc.)

• The application name or identifier and version

• The function, module, feature, object, screen, etc. where the bug occurred

• Environment specifics, system, platform, relevant hardware specifics

• Test case name/number/identifier

• One-line bug description

• Full bug description

• Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool

• Names and/or descriptions of file/data/messages/etc. used in test

• File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem

• Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)

• Was the bug reproducible?

• Tester name

• Test date

• Bug reporting date

• Name of developer/group/organization the problem is assigned to

• Description of problem cause

• Description of fix

• Code section/file/module/class/method that was fixed

• Date of fix

• Application version that contains the fix

• Tester responsible for retest

• Retest date

• Retest results

• Regression testing requirements

• Tester responsible for regression tests

• Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

Key features of QTP

QTP enables even an inexperienced tester to work with as it is GUI based. Major advantages it has are active screen which allows user to insert checkpoints when the application is closed, testers job is made simple with different features it has, debug viewer where in we can see what values variables carry when the test is running, and many features made simple.

- Key word driven testing
- Suitable for both client server and web based application
- Vb script as the script language
- Better error handling mechanism
- Excellent data driven testing features
- Operates stand-alone, or integrated into Mercury Business Process Testing and Mercury Quality Center.
- Introduces next-generation “zero-configuration” Keyword
- Driven testing technology in quick test Professional allowing for fast test creation, easier maintenance, and more powerful data-driving capability
- Identifies objects with Unique Smart Object Recognition, even if they change from build to build, enabling reliable unattended script execution
- Collapses test documentation and test creation to a single step with Auto-documentation technology
- Enables thorough validation of applications through a full complement of checkpoints
- Ease of Use, Simple Interface, Simple scripting Language (VBScript), Use of Zero-Configuration Technology, Automatic Insertion of Checkpoints, Marvelous Interface with Data-tables, Better Object Identification Mechanism, Support of Variety of Environment, Easy Adaptability of Microsoft Object Models, Auto-Documentation Technology
- qtp is mainly used for functionality testing. QTP is user friendly both technical and non technical users can easily access. QTP has two views
keyword view and expert view : in keyword view when u record a test it generates the script in tree format. it is very easy to understand. if u want to view the vb-Script use the expert view.
qtp has active screen using that u can enhance the script with out navigating to the application. like u can insert checkpoints and synchronization points.
qtp has automated documentation. When u start recording it generates the auto documentation in plain english.
using qtp we can parameterize objects, checkpoints, data-driven tables. this will give more flexibility.

QTP Vs Selenium

1. Actual end user simulation, Is the test conducted using this tool equivalent to an end user action?
Selenium performs actions in the background on the browser. It modifies the DOM structure of the HTML page in order to perform actions on the page. To be more precise it executes javascript on UI objects within the webpage to perform actions like click, type, select etc. This is the reason why you can execute tests with the browser minimized.

QTP claims to perform end user simulation, in other words executing QTP scripts is equivalent to a person performing those steps manually on the application.

2. Support for most UI Components
Selenium Certain events, methods and Object properties are not supported by selenium. But broadly most UI components are supported.

QTP requires extra add-ons (plug-in, not free) to work with .Net components.

3. UI-Object management & storage
QTP comes built-in with object repository. Object

repository management is quite easy in QTP. Selenium has no such built in feature but objects can be managed using UI-Element user extension. Other custom solutions like properties files can also be used in selenium. But for all such solutions the map file in selenium has to be hand-coded i.e unlike QTP the objects won't be recorded/added automatically .

4. Support for Dialog Boxes

QTP supports all kinds of IE dialog boxes. There is partial support for dialog boxes in Selenium. Some actions like retrieving the title of he dialog box can't be performed in selenium.

5. Support for web browsers

QTP supports IE & Firefox. Selenium supports

IE, Firefox, Safari and Opera and a few more browsers. But either tools are far far away from full cross-browser support. Don't expect scripts created using browser to run flawlessly in another browser.

6. Object Recognition Parameters, Recognition on the basis of WYSWYG (what you see is what you get).

Selenium recognizes objects on the basis of the DOM structure of the HTML Page. The UI objects in selenium have vague descriptions and don't comply with WYSWYG policy.
QTP recognises and names objects based on properties which are more visible and obvious and are hence the objects have user friendly names.

7. Object Oriented Language support &Scalability (as in Integration with External tools utilities and libraries).

Selenium Supports JAVA, dot net and many other industry standard programming languages. QTP supports vb script only.

8. Integration with test management tool.

QTP integrates seamlessly with QC and TD. Test management and mapping the manual testing process with automation becomes a lot easier with this integration. I have not yet heard of any test management tool that can integrate seamlessly with Selenium. keep an eye out for Bromide though.

9. Types of application supported

QTP wins this one hands down. This is one of the main reason why selenium can't even be considered in many cases. Imagine real-time applications like trading terminals, risk management applications built in TCL/TK and PowerBuilder. QTP supports most of these interfaces.

Selenium on the other hand can work only on applications that open up inside a browser. But aren't most applications moving to the browser based platform? :)

10. Support for operating system/platforms

Selenium Supports JAVA and hence can be used in Windows PC or MAC or UNIX. Using selenium you can test your web application in all the above platforms. QTP supports Windows only.

11. Ease of creation of Scripts

Selenium IDE Recorder is not as powerful as QTP but is good for a free tool, many actions are not recorded by the IDE and have to be manually entered.

12. Technical Support

QTP offers technical support by phone and mail, HP also have a web-forum.

QTP user community is vast and questions posted on online forums get answered quickly. Selenium being an open source tool has no official tech support, the user community is small, less-active and questions on forums seldom get answered. But the community is growing day by day as the tool gains acceptance.

13. Cost

QTP - Costly, Many people want to switch to selenium because it's free. But cost isn't really a factor when your client's a investment bank :)
14. Test Development Environment

When you are working on selenium you have the option of using wide range of IDEs like Eclipse, Netbeans, Visual Studio etc depending on your choice of development language. If you are a developer then you must have developed a taste for rich IDEs and switching to a environment given by a test tool may be hard for you.

QTP tests can only be developed in QTP.

15. Integration with development process

Tests developed using selenium can be easily part of the development project. Using tools like cruise control Continuous Integration is easier with Selenium. But don't get too caught up with this feature, it's really not that important to be integrated with the development process but it's nice to have.

16. Future in terms of usability and acceptance

The future bodes well for selenium because it's free, supports all programming languages/platforms and is immensely scalable and expandable due to it being free and open source. Many pundits have predicted that it will completely conquer the web testing market in the next 5 years. It being free makes a huge difference especially when times are hard like what we have now.

QTP on the other hand is the current market leader and I think that it will have it's presence for long due to it's user friendliness and support for interfaces other than web.

Fear

There was a lion who feared nothing except the crowing of cocks. A chill would go down his spine whenever he heard a cock crowing.One day he confessed his fear to the elephant, who was greatly amused. “How can the crowing of a cock hurt you?” he asked the lion. “Think about it!”, Just then a mosquito began circling the elephant’s head, frightening him out of his wits.“If it gets into my ear I’m doomed!” he shrieked, flailing at the insect with his trunk.Now it was the lion’s turn to feel amused.

Moral: If we could see our fears as others see them we would realise that most of our fears make no sense!

What is Software Testing and Why is it Important?

A brief history of Software engineering and the SDLC.

The software industry has evolved through 4 eras, 50’s –60’s, mid 60’s –late 70’s, mid  70’s- mid 80’s, and mid 80’s-present. Each era has its own distinctive characteristics, but over the years the software’s have increased in size and complexity. Several problems are common to almost all of the eras and are discussed below.

The Software Crisis dates back to the 1960’s when the primary reasons for this situation were less than acceptable software engineering practices. In the early stages of  software there was a lot of interest in computers, a lot of code written but no established standards. Then in early 70’s a lot of computer programs started failing and people lost confidence and thus an industry crisis was declared. Various reasons leading to the crisis included:

Hardware advances outpacing the ability to build software for this hardware.
The ability to build in pace with the demands.
Increasing dependency on software’s
Struggle to build reliable and high quality software
Poor design and inadequate resources.
This crisis though identified in the early years, exists to date and we have examples of

software failures around the world. Software is basically considered a failure if the project is terminated because of costs or overrun schedules, if the project has  experienced overruns in excess of 50% of the original or if the software results in client  lawsuits. Some examples of failures include failure of Air traffic control systems, failure  of medical software, and failure in telecommunication software. The primary reason for  these failures other than those mentioned above is due to bad software engineering practices adopted. Some of the worst software practices include:

No historical software-measurement data.
Rejection of accurate cost estimates.
Failure to use automated estimating and planning tools.
Excessive, irrational schedule pressure and creep in user requirements.
Failure to monitor progress and to perform risk management.
Failure to use design reviews and code inspections.

To avoid these failures and thus improve the record, what is needed is a better understanding of the process, better estimation techniques for cost time and quality measures. But the question is, what is a process? Process transform inputs to outputs i.e. a product. A software process is a set of activities, methods and practices involving  transformation that people use to develop and maintain software.

At present a large number of problems exist due to a chaotic software process and the occasional success depends on individual efforts. Therefore to be able to deliver  successful software projects, a focus on the process is essential since a focus on the product alone is likely to miss the scalability issues, and improvements in the existing  system. This focus would help in the predictability of outcomes, project trends, and  project characteristics.

The process that has been defined and adopted needs to be managed well and thus process management comes into play. Process management is concerned with the  knowledge and management of the software process, its technical aspects and also  ensures that the processes are being followed as expected and improvements are  shown.

From this we conclude that a set of defined processes can possibly save us from software project failures. But it is nonetheless important to note that the process alone cannot help us avoid all the problems, because with varying circumstances the need varies and the process has to be adaptive to these varying needs. Importance needs to be given to the human aspect of software development since that alone can have a lot of
impact on the results, and effective cost and time estimations may go totally waste if the human resources are not planned and managed effectively. Secondly, the reasons mentioned related to the software engineering principles may be resolved when the needs are correctly identified. Correct identification would then make it easier to identify the best practices that can be applied because one process that might be suitable for one organization may not be most suitable for another.

Therefore to make a successful product a combination of Process and Technicalities will be required under the umbrella of a well-defined process. Having talked about the Software process overall, it is important to identify and relate the role software testing plays not only in producing quality software but also maneuvering the overall process.

The computer society defines testing as follows: “Testing -- A verification method that applies a controlled set of conditions and stimuli for the purpose of finding errors. This is the most desirable method of verifying the functional and performance requirements.Test results are documented proof that requirements were met and can be repeated.

The resulting data can be reviewed by all concerned for confirmation of capabilities.”

There may be many definitions of software testing and many which appeal to us from  time to time, but its best to start by defining testing and then move on depending on the requirements or needs.

Defect Removable Efficiency (DRE)

The Defect Removable Efficiency (DRE) is the percentage of defects that have been removed during an activity, computed with the equation below:
DRE = (Number of Defects Removed / Number of Defects at Start of Process) * 100

The DRE can also be computed for each software development activity and plotted on a bar graph to show the relative defect removal efficiencies for each activity. Or, the DRE may be computed for a specific task or technique (e.g. design inspection, code walkthrough, unit test, 6 month operation, etc.)

We can also calculate DRE as:

DRE = A / (A+B)

where A = Defects by raised by testing team and B = Defects raised by customer

If dre <=0.8 then good product otherwise not.

Bibhas Kumar Senapati: Top 20 practical software testing tips you can use for testing any application.

Bibhas Kumar Senapati: Top 20 practical software testing tips you can use for testing any application.

Top 20 practical software testing tips you can use for testing any application.

1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.


2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.

E.g.: Let’s assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions (positive test cases) according to requirements. Then write test cases for invalid conditions (Negative test cases). This will cover expected as well unexpected behavior of application under test.

5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also. This is otherwise called as ‘Testing with Attitude’

6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

8) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10) Programmers should not test their own code. Basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger knows when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11) Go beyond requirement testing. Test application for what it is not supposed to do.

12) While doing regression testing use previous bug graph (Bug graph - number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17) Testing teams should share best testing practices, experience with other teams in their organization.

18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute - make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.

19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.