Software Test Automation Job Interview Questions

Hi,
Here is a list of probable "Software Test Automation" interview questions.

1. What automating testing tools are you familiar with?
2. How did you use automating testing tools in your job?
3. Describe some problem that you had with automating testing tool.
4. How do you plan test automation?
5. Can test automation improve test effectiveness?
6. What is data - driven automation?
7. What are the main attributes of test automation?
8. Does automation replace manual testing?
9. How will you choose a tool for test automation?
10. How you will evaluate the tool for test automation?
11. What are main benefits of test automation?
12. What could go wrong with test automation?
13. How you will describe testing activities?
14. What testing activities you may want to automate?
15. Describe common problems of test automation.
16. What types of scripting techniques for test automation do you know?
17. What are principles of good testing scripts for automation?
18. What tools are available for support of testing during software development life cycle?
19. Can the activities of test case design be automated?
20. What are the limitations of automating software testing?
21. What skills needed to be a good software test automator?
22. How to find that tools work well with your existing system?
23. Describe some problem that you had with automating testing tool.
24. What are the main attributes of test automation?
25. What testing activities you may want to automate in a project?
26. What are some of the common misconceptions during implementation of an automated testing tools for the first time?

What is a Web Service?

The W3C defines a Web Service as a software system designed to support interoperable machine to machine interaction over a network. Web services are frequently just API's that can be accessed over a network, and executed on a remote system hosting the requested services.

Among the many ways devised to enable humans to use software running on distant computers, HTML transported over HTTP and presented via a web browser is surely the most successful yet. By using this relatively simple, accessible message format, applications can be used by people all over the world without installing custom client software on their computers.

What about when you want to connect one system to another that is running on a distant computer? Lots of approaches to distributed computing have been tried over the years, and many of these are still in use. But none has achieved the same degree of explosive growth and re-use as we have seen with HTML for web UI. The term "web services" encompasses applications that employ a specific combination of technologies to make themselves accessible to other systems running on remote machines. The most significant web services technologies address three questions:

• How do I find web services that I want to use?
• Once I find a service, how do I learn how it works?
• How do I format messages to a web service?

Finding a Web Service:

In the simplest case, you could learn about a web service in the normal course of communicating with your friends, co-workers and business partners. Universal Description, Discovery and Integration (UDDI) offers a more structured approach. UDDI is a standard for establishing and using registries of web services. A company could establish its own private registry of web services available internally, or to its partners and customers. There also are several public UDDI registries that anyone can search, and to which anyone can publish the availability of their own web services.

Understanding a Web Service:

Once you identify a web service that you'd like to use, you need to know how it works: What kinds of messages does it respond to? What does it expect each message to look like? What messages does it return, and how do you interpret the responses? The Web Services Description Language (WSDL) provides a way to declare what messages are expected and produced by a web service, with enough information about their contents to enable using the service successfully with little or no additional information. When you create a web service, you can create a description of the service using WSDL and distribute the description file (often called a WSDL file) to prospective users of the web service, either directly or by including a link to the WSDL file in a UDDI registry entry.

Communicating With a Web Service:

Now that you've obtained the WSDL description of a Web Service, you're ready to invoke it. Web Services communicate with one another via messages in a format known as XML. XML (Extensible Markup Language), like HTML, is a descendent of Standard Generalized Markup Language (SGML). HTML focuses on the way information is to be presented. XML, on the other hand, focuses on the structure of the information, without regard to presentation issues. That's one reason XML is well suited to exchanging information between automated systems. Web services exchange XML messages with one another, typically using either HTTP or SMTP (e-mail) to transport the messages. The Simple Object Access Protocol (SOAP) is a further specification of how to use XML to enable web services to communicate with one another. A SOAP message is just an XML message that follows a few additional rules, most of which deal with how the elements of the message are encoded, and how the message as a whole is addressed.

A Strategy for Planning

Here is a good article on ST.

--------------------------------------

Traditionally, strategic planning has been a process that involves documenting business goals and objectives, then developing specific plans and initiatives to achieve the desired end state. This process while effective, is limited in several ways. Strategic planning is often bounded by management perspective, is not inclusive of diverse thinking, and does not stimulate innovation.

full article here

Life Cycle of a Software Bug

Bug tracking workflow, i.e., the lifecycle of a bug or defect, describes the states of the bug or defect from it is created to it is closed. The following are some commonly used terms for software bug tracking (if you are in a hardware or help desk customer support situation, it could be completely different):

new

When a bug is newly created, it has a state 'new'. Some people separate this 'new' state into two states, namely, 'open' before the bug is assigned and 'assigned' after the bug is assigned. In the case of Bugzero, since a newly created bug is always assigned, you may just call it 'new' or 'open' without the 'assigned' state.

You still can have an 'assigned' state if you decide to have all the newly submitted bugs to be sent to a manager (with 'new' state), and the manager then really assigns the bug. You can configure the workflow such that the next allowed state for 'new' is 'assigned'.

open

Some people call a newly created and yet to be assigned bug a state 'open'.

assigned

Some people call a newly created and assigned bug a state 'assigned'.

fixed

A bug that has been fixed by a developer has a state of 'fixed'. Normally, this is a state before the bug is confirmed (by QA) to be really fixed. If a bug is confirmed to have been fixed, it should have a state of 'closed'. Some systems allow you to configure that, only Developers can fix a bug.

resolved

Similar to 'fixed'.

closed

If a bug is confirmed (by QA) to have been fixed, it should have a state 'closed'. Some systems allow you to configure that, only QA can close a bug.

reopened

A 'closed' bug can be re opened if it re-surfaced or it is found to be not really fixed.

suspended

A bug can be 'suspended' if it is determined that the bug should not be fixed immediately or a fix can be delayed. Some people call it 'deferred'. Some systems allow you to configure that only a certain person, such as a Manager, can suspend a bug.

deferred

Similar to 'suspended'.

analyzed

If more information is needed to fix the bug, it can be conveniently set to a state 'analyzed'. You may want call it a different name, such as 'update'.

List of Defect Tracking Tools

This is a list of defect tracking tools. Both commercial and freeware tools are included. The tools on this list are all available standalone, with the exception of a few that are integrated with a test management system. For More details, check out - http://www.testingfaqs.org/t-track.html +1CR (+1 Software Engineering) Aardvark (Red Gate Software Ltd.) Abuky (freeware) AceProject (Websystems Inc.) AdminiTrack (AdminiTrack, Inc.) Advanced Defect Tracking (Borderwave Software) Alcea Fast BugTrack (Alcea Technologies Ltd.) AllChange (Intasoft) AQdevTeam (AutomatedQA Corp.) Atlassian JIRA (Atlassian Software Systems) BitDesk (PTLogica) BridgeTrak Suite (Kemma Software) Bug Trail Bug-Track.com BugAware (Jackal Software Pty Ltd) BugBase 2000 (Threerock Software) BugBox (BugBox) Bugcentral.com (Bugcentral Inc.) BugCollector Pro (Nesbitt Software Corporation) Bug Cracker (Fe Software & Development) Bug/Defect Tracking Expert (Applied Innovation Management, Inc.) Buggit (freeware) Buggy (Novosys EDV GmbH) BugHost (Active-X.COM) BugLink (The PandaWave) BugLister (Hajo Kirchhoff) BugMonitor.com(BugMonitor.com, Inc.) BugRat (freeware) BugStation (Bugopolis LLC) BUGtrack (ForeSoft Corporation) Bugtrack (freeware) Bug Tracker Software (Bug Tracker Software) BugUP Bugzero (WEBsina) Bugzilla (freeware) Census Bug Tracking and Defect Tracking (Metaquest) Change Commander (Lightspeed Software) ChangeSynergy (Telelogic AB) ClearDDTS (Rational) ClearQuest (Rational) CustomerFirst (Repository Technologies, Inc.) Debian Bug Tracking System (freeware) Defect Agent (Inborne Technology Corporation) Defect Manager (Tiera Software, Inc) Defect Tracker (New Fire) Defect Tracker (Pragmatic) defectX (defectX) Deskzilla DevTrack (TechExcel, Inc) Dragonfly (Vermont Software Testing Group) d-Tracker (Empirix) DuxQA (ID Consultants) elementool (elementool Inc.) eQRP (Amadeus International Inc.) ExtraView (Sesame Technology) Flats Helpdesk (WarrinerWare) FMAS (stag software private limited) FogBUGZ (Fog Creek Software) GNATS (freeware) GRAN PM (GRAN Ltd.) Helis (freeware) icTracker (IC Soft, Inc.) inControl (stag software private limited) IOS/Track (Interobject Systems) IssueView (IssueView.Com) ITracker(Cowsultants.com) JitterBug (freeware) JTrac LegendSoft SPoTS (LegendSoft Inc.) Mantis (freeware) McCabe TRUEtrack (McCabe & Associates, Inc.) NeumaPT (Neuma Technology Corporation) OfficeClip Defect Tracker (OfficeClip. LLC) OnTime Defect Tracker Ozibug (Tortuga Technologies) Perfect Tracker (Avensoft) PloneCollectorNG (ZOPYX Software development and consulting Andreas Jung) Problem Reporting System (Testmasters, Inc) ProblemTracker (NetResults) ProjectLocker (One Percent Software) ProjectPortal (Most Media) ProjecTrak Bug Tracker (Eden Communications) PR-Tracker (Softwise Company) PVCS Tracker (Merant) QAS.PTAR (Problem Tracking and Reporting) QuickBugs (Excel Software) RADAR (Cosmonet Solutions) Razor/PT (Visible Systems Corporation) Remedy Quality Management (Remedy Corporation) RMTrack (RMTrack Issue Tracking Solutions Inc.) Roundup (freeware) Scarab (freeware) SilkRadar (Segue Software, Inc.) SourceAction SourceCast(CollabNet, Inc. ) Support Tracker SWBTracker (Software with Brains Inc.) Squish (Information Management Services, Inc.) T-Plan Incident Manager (T-Plan) TeamTrack (TeamShare, Inc.) Team Tracker (hs technologies pty ltd.) TestTrack Pro (Seapine Software) Trac (Edgewall Software) Trackem (Pikon Innovations) Tracker (freeware) TrackStudio Enterprise (TrackStudio, Ltd) TrackWeb Defects (Soffront) Trackgear (LogiGear) TrackRecord (Compuware) Trackwise (Sparta Systems) Visual Intercept (Elsinore Technologies) vManage WebPTS (Zambit Technologies, Inc.) yKAP - Your Kind Attention Please (DCom Solutions) ZeroDefect (ProStyle Software Inc.)

List of Test Case Management Tools

Here is a list of Test Case Management Tools. These tools help organize and execute groups of test cases, also called test suites. Some tools are for automated tests, some for manual tests, and some handle both. Aegis ApTest Manager AutoAdviser Chrysilla Test Case Tool CONVEX Integrated Test Environment (CITE) DejaGnu EasyTest kSETT QADirector QaTraq QCIT QES/Architect QES/EZ QMTest rth SMARTS Software Testing Automation Framework (STAF) SpiraTest TEO Test Case Manager (TCM) T-Plan Professional TestDirector Testify Test Manager Test Library Manager Test Station TET (Test Environment Toolkit) TETware TMS

Selecting the best defect tracking system

The following is a general comparison overview of Bug Tracking Tools. It is focused particularly on the technical aspect. The aim is to help you to select the best tracking system that meets your requirement. Click on the link for a more detailed comparison between Bugzero, Bugzilla, and Gnats.

System Architecture:

• Many old bug or defect tracking systems are client server based. You need install the server, and each user need install the client software. If external users were involved, it could be problematic because of issues like firewall etc. Also, it is not always feasible to install client software.
• Newer systems are more likely web browser based and no client software need to be installed (except a browser). A web-based bug tracking system is especially attractive if your users are located in different locations and are connected through the internet.
• For a web-based bug or defect tracking system, make sure it supports the browsers your users are using. Be aware that many systems support only IE.

Server Operating System:

• Most commercial bug tracking systems are Windows based. In such a case, it is likely that it requires an NT/2000/XP server and a SQL Server database. Note that, a Windows XP Professional may not be sufficient, instead, a server may be required.
• Most free bug or defect tracking systems are Linux/Unix based, and may not work as well on Windows. It may also require more technical skills to install and setup the system.
• When people say their system is cross-platform, you need make sure they meant the server. Only a very few bug tracking systems are really cross-platform (with the same code base). Some vendors claim to support multiple OS, but they have completely independent versions for each OS and that results in higher costs for the vendor and therefore higher price for the end users.

Backend Database:

• Most bug or defect tracking systems require a backend database, but a few are file based. In the latter case, make sure it scales well. If someone tells you that a file based system is better than a database, think twice.
• For Windows based systems, database selection may be limited to only Access and SQL Server. On the other hand, some free systems may lock you into just one database, notably MySQL. Only a very few bug tracking systems are really cross database systems.
• Be aware of any bug tracking software that uses non-standard proprietary databases. They cannot be better than the public, commonly used database systems.

Language Support:

• Many bug tracking systems do not support localization, particually, Asian langauges. Note that, it involves the web interface, the data, and the email notification.
• If you do need localization, you should find a system that can do that easily.

Web Server:

• For Windows based bug tracking systems, most likely it requires IIS as the web server.
• For Java-based bug tracking systems, a Servlet or J2EE server is most likely required. There are many high quality servers you can download for free.

Programming Language:

• Most of the bug tracking systems are written in either c/c++, or perl/php, or Java.
• Depending on your IT environment and skill set, the programming language may be relevant in selecting your system. For example, if you are developing Java software, it may make sense to use a Java based bug tracking system.

Version Control Integration:

• Some bug tracking systems have the capability of integrating with source control systems, such as CVS, Source Safe, etc.
• Be aware of the limitations, and make sure it does the things you want.

Installation and Configuration:

• A bug tracking system is not a desktop application and it rarely works out-of-the-box. It is not uncommon to spend a few hours to setup such a system, and then more time to customize it.
• However, if you need only a lightweight bug tracking system, a heavy, complex, can-do-everything system is certainly a over kill and it may do more harm than good.

Maintenance and Support:

• A bug tracking tool is not a super complex software system, but from time to time you may need technical support. As you certainly know, in most cases, the error messages from these systems are always cryptic, and you won't be able to solve the problem on your own.
• How is the error handled in a tool is far more important than you might think. You as the administrator may want select a tool that you feel comfortable to work with.
• When support is needed, it is always urgent to you, but not necessary to the vendor. Before you purchase the software, you should ask what is the response time for support.

Features:

• Simple is the key here. The system must be simple that people like to use it, but not so complex that people avoid to use it. You might not want to deploy a tool that requires serious end user training. It is really not the initial training, rather the on-going support needed from your end users that you should be concerned with.
• Yet it should be flexible and configurable enough to satisfy your business needs. If you select a tool that cannot do whatever you intend it to do, then what is the use of it?

Cost of Ownship:

• The initial cost of a bug tracking system varies from free to tens of thousands of dollars. But be aware that this is not the same as the total cost of the ownership. Some free systems charge a hefty consulting fee for support and you may end up paying much more than you planned.
• You should select a bug tracking system based on your needs, not just the price. If you know what you are doing and do not need commercial support, go for a free one if it meets your requirement.
• However, if you unfortunately selected a bad one, you better get out of it as soon as possible, because the longer you keep it, the more moeny and time you will have to spend on it.

In any case, spending many days to setup a free system or even weeks or months to create an in-house system makes no business and economic sense, because if you consider the time spent, you are actually paying much more than just buying one.