Day by day, software testing becomes very crucial, since the applications are developed in different languages on different OS. Also, the complexity of the software is getting increased. The difficulty in software testing stems from the complexity of software. Regardless of complexity, we need to achieve high quality in our products. Test automation is one of the robust and fastest solutions for achieving quality in a complex environment. Automated testing can provide several benefits when it is implemented appropriately.
Automation is a good way to cut down time and cost.

The significant benefits of automated tests are:

• Production of a reliable system
• Improvement of the quality of the test effort
• Reduction of the test effort
• Testing a large test matrix (different languages on different OS platforms)

Due to the growing complexity of the software, there are multiple challenges in GUI test automation:

• Application window name is dynamically changing
• Mix of Managed and Unmanaged UI controls
• Applications developed in multiple languages and multiple OS
• Controls that don’t have proper and unique text property
• Customized controls and Owner draw controls
• Applications that are using third party controls like source grid control
• Class names are dynamically changing
• Controls that don’t have proper Z order
• GPIB command support
• More visual controls

What if the testing tool has limitations to support all the above challenges? Then we have only two options:
Either reevaluate our testing plan from automation to manual or look for a new testing tool. Obviously it makes software testing very costly.

Is it possible to overcome all the challenges in Single automation tool?

The answer is Yes. In our organization, we have developed our own GUI automation tool called TekRobo.  This paper describes:

• What is TekRobo GUI automation tool
• How it handles all the challenges in test automation
• How it helps us to Achieve high quality in Complex environment

Mohan Das Gandhi holds a Master’s degree in Applied Electronics from PSG CAS, Coimbatore, Tamilnadu, India. He is presently employed by a US based company, Tektronix  Engg Devp. (I) Pvt Ltd in Bangalore as a Software Quality Leader. He has worked for Tektronix for the past 10 years and, overall, has 12 years of experience in the IT industry. He has vast experience in GUI test automation tool development and has done a lot of research in GUI test automation. Last year he submitted two papers ("Improvements in GUI testing of TekScope application for DPO/DSA Tektronix Oscilloscope Series" and "Automated GUI Stress Testing using GUIStressRobo") to PNSQC, both of which were selected as poster papers.

Software testing on a computer system starts with a known initial state. Testing is conducted to assure the functional quality of the software in the environment that is controlled by the computer. Software written for a robot faces additional challenges. The software on the robot needs to function in a physical environment where the initial state may not be precisely known and the behavior is not precisely controllable. On top of these problems, the software on the robot faces a complex environment that may
have many factors that are changing as the robot is tested.

This paper explores the challenges of testing software on a robot in the physical world. Through the case study of running a LEGO robot with motors and sensors on a FIRST LEGO League competition table, it characterizes the environment factors, some of which are not controllable. Through the sensors that are available on a robot, it characterizes the uncertainties from the sensor readings and the location of the robot. It then describes how it employs a software testing process to test if the robot
can perform missions reliably given the less than perfect environment and sensors.

The software testing approach in the physical world has only scratched the surface of the complexity of the quality assurance of a robot. Early results from the case study here demonstrates that taking lots of sensor readings, establishing a relationship between the sensor data and the results of the experiments would simulate testing on the equivalence of many different environments and reduce the number of runs to catch failures.

The contributions of this paper are:

1. Characterization of environment factors in a complex system such as the physical world.
2. Establishing a method to develop the relationship with imprecise sensor readings and the functionality of the software on the robot.
3. Applying the relationship to improve the software testing process to assure the quality and reliability of the robot.

Kingsum Chow is a principal engineer from the Intel Software and Services Group (SSG). He has been working for Intel since receiving his Ph.D. in Computer Science and Engineering from the University of Washington in 1996. He has published more than 40 technical papers and patents. Outside of work, he has coached a FIRST LEGO League team since 2006.

Abandoning Spreadsheets for Test Data – Case Study with TestLink
Richard Vireday

At the end of 2009, our group was struggling with lots of test data and spreadsheets that could not capture the information. To grow our capabilities, before we chucked the spreadsheets, we installed and configured the open-source tool TestLink to help manage our data. So far, it has worked great even though we can’t use many of the automation capabilities because of the nature of our testing. It has however, enabled us to better organize our testing as well as consolidate to one repository. There are still some gaps in TestLink, but the active development and improvement lists show a promising growth.

This would be a case-study, with data from 1+ year of use.

Richard Vireday is a long time PNSQC contributor and volunteer.

Hacker’s Envy, Tester’s Pride: Top 10 Commandments for Securing your Web Applications
Sushil Karwa, McAfee
Sasmita Panda, McAfee

Most of us are aware of the consequences that can occur in face of any security flaw being exploited by a malicious user. Addition of security to our test agenda has gained a lot of momentum in recent years. Web applications face ubiquitous and ever-growing security threats from nasty users, insiders, hackers and others. This paper talks about how to test security of web applications in a comprehensive manner. There is a plethora of resources trying to address the questions like “Why security?”, “What to test for security?”, “Who should test security?”, “When to start security?” or “Where to look for security?”. In this paper you will find the answer to one of the basic yet very vital questions: “How to test for security of web applications?”.

In this paper presentation the authors have framed a guideline that security testers can adopt while performing security testing for Web Applications. With the help of these guidelines, one would be able to produce repeatable, unswerving tests that fit into the overall testing strategy, but that address the security side of web applications. Building security tests using these guidelines will help you to discover flaws in the source itself: fault in how it executed its business functions. Using
this structured approach will help you to come up with well-defined security tests that assist root-cause analysis deep down to the lines of code that cause the problem.

The guidelines explained in this paper are quite comprehensive but by no means exhaustive. This paper explains about the top 10 ways to test a Web application in a meticulous manner. These include both manual and automated ways of testing web applications’ security, and more importantly we will be focusing more on “how” to test for these security areas of Web application with real examples and demos. Here is a glimpse of what we will be discussing in this paper as part of top 10 ways to test web
applications security:

• Basic observation and investigation of web application
• Tampering with Input and using Bad data
• In quest of design and logic flaws
• Having a session with Sessions in your web application
• Versatile Security tests
• Security and Automation

Target Audience:
QA Engineers, QA Leads, Security Testers, Developers

Sushil Karwa is a QA Technical Lead at McAfee. He has a Master’s degree in Quality Management from BITS Pilani University, India. His testing and QA experience include a focus on white box test automation for a web-based product. He has been associated with McAfee for the last 7 years. His role involves identification of security risks, threat model preparation, security code audits and test planning for security management framework. At McAfee, he has been involved in initiating and implementing the white box test automation process for various product teams. Sushil is a Certified Ethical Hacker and Security Analyst from EC-Council, USA.

Sasmita Panda is a Senior QA Engineer at McAfee and works with the Host Intrusion Prevention System product team. She has a Master’s Degree in Computer Application from Madras University, India. Her testing and QA experience include a focus on white box testing automation, security testing and identification of different techniques for measuring code coverage.

Achieving Quality in a Complex Environment can be very difficult. A main factor in the “complex” environment is that there is so much to focus on but so little time. With methodologies like agile development gaining significance by the minute, it is very hard for QA to keep up with the rapid pace of the project. Similarly, development also is finding it hard to focus on the non-functional aspects of the product like performance and security.

This paper outlines the approach that we at McAfee adopted to overcome these challenges with the goal of achieving quality in a complex environment.

The paper primarily focuses on the a few practices that can reduce the time taken for performance testing during the agile project life cycle and at the same time provide equal if not better coverage of testing as compared to the traditional project life cycle.

The practices the paper will explore include:

1. Setting up performance goals: While this is not something new in the agile model only, it definitely gains much more significance. What are the key aspects that we need to define very early in the project life cycle in order to come up with an objective rather than subjective list of goals? What methods can be employed in order to come up with this list? These are some of the questions that this paper will try answer.
2. Eliminating performance issues: Again, this is not new, but in the context of “time” this is of very high importance. The paper will try to outline some key aspects that need to be reviewed. Also some general guidelines regarding development best practices to avoid performance issues will be highlighted.
3. Automated performance testing: From one of the key agile concepts of “Test early, test often” it is evident that automation is one of the key aspects that will enable teams to shrink performance test runs and allow for repeated performance tests. Discussions around the requirements, out of a performance test automation framework, in terms of robustness and flexibility will be highlighted.
4. QA skill set development: Another key area where time is spent in performance test phase is debugging the cause of performance issues. It is relatively easy for QA to test and collect performance metrics, but when an issue is encountered, the root cause of the issue is not evident right away. Development puts in a lot of effort trying to reproduce the issue and then debug the same. QA needs to develop the skills to perform initial analysis. This can be greatly helped by tooling. The paper
   lists some tools and their advantages along with examples of analyzing performance issues.
5. Tracking performance: Tracking performance numbers on a very high frequency basis allows for narrowing down the cause of the issue. The performance issues, which are introduced into the product over builds, can be tracked and fixed as they occur.
6. Involve third parties: Having Beta and JDP programs will help in ensuring production environment testing for performance. Create appropriate scenarios and enable the participants with tooling. The paper will list methods and suggestions on creating scenarios and automation that will help in delivering the product for Beta testing.

The key contents of this paper will be in these lines:

1. Setting up performance goals:
1. Define components and workflows targeted and work towards that target.
2. Define percentage improvement for above.
3. Have regular performance review meetings.
2. Eliminating performance issues:
1. Review of architecture diagrams and related design documents. (For new products)
2. Analyze existing behavior for bulky functions and feed this back into requirements of newer versions. (For mature products)
3. Examples of typical performance issues that should be avoided (like network operations during boot, encryption/decryption during boot, trying to start multiple processes without ordering them, making multiple calls for some properties, etc.).
3. Automation
1. Allows for testing often.
2. Start tests very early (have the framework ready earlier)
3. Examples of a good framework.
4. QA skill set improvement
1. QA needs to build skill set to do initial analysis. (Saves time where dev is doing the analysis.)
2. Use appropriate tooling.
3. Examples from xperf.
5. Tracking performance
1. Run performance tests on every build (or RTQA).
2. Track numbers graphically.
3. Narrows down root cause tracking (to within a few svn check-ins).
6. Involving JDP/Beta
1. Get external tests ready to expose your app to real world scenarios.
2. Agile allows for late changes, so make changes from the Beta/JDP feedback.

Vikram Gopinath works for the enterprise system security solutions team at McAfee India Private Limited. Vikram has experience in areas like performance, security and functional testing.

Uday Ravi Kempegowda works for the enterprise system security solutions team at McAfee India Private Limited. Uday has experience in areas like performance, security and functional testing.

Although the concepts behind service-oriented architecture (SOA) have been around for over a decade, SOA has gained extreme popularity of late due to web services. If you’re in the market for a superb tool for testing of web services, SoapUI will fit the bill.

SoapUI supports functional testing of Web Services by providing a TestCase metaphor where a number of TestSteps can be executed in sequence. It also allows easy content transfer between responses and request.

The paper presentation will include 4 parts as such:

1. Current challenges in testing
2. Functional Web Services testing using SoapUI
3. SoapUI and Automation
4. SoapUI and Continuous Integration

Meera Subbarao works as a Senior Software Consultant for Cigital, Inc., which specializes in software security and quality. Meera has eighteen years of software programming experience. Prior to joining Cigital, Meera was a Senior Software Consultant for Stelligent, where she helped customers create production-ready software using Agile practices. She is a Sun Certified Java Programmer as well as a Sun Certified Web Component Developer. Meera has articles published regularly in online publications and frequently speaks at conferences like SD West 2009 and Software Test and Performance Conference.

Server products operate under complex conditions with unpredictable workload characteristics, concurrency rates,
infrastructure conditions, operational demands and resource utilization. Driving for high quality in such cases is extremely difficult, particularly when production and testing environments lack consistent, symmetric monitoring methods and models to aid in diagnosing issues, predicting failure rates after ship, discovering product flaws and assessing readiness to ship.

One way to solve part of this problem is to establish monitoring tools and methods that map an end user based view of software quality to a product engineering based view of system flaws and failures. By basing the metrics on experiences that map directly to impact, you can focus the product team time on issues that will truly matter to the customer. By building a monitoring solution that can be applied in both production systems and in test environments you enable a quality feedback loop that facilitates improved test engineering, product design, investigational methodology and ship schedule management.

This paper presentation will describe how the SharePoint 2010 team deployed such a solution for monitoring both in-house production environments and performance and stress testing lab environments. It will describe the components in the solution that span in-product instrumentation, custom solutions built on existing product features, as well as team methods and processes for monitoring and triaging issues coming from production systems. It will demonstrate the gains we achieved in bug discovery yield, improved fix rates and more successful pre-release production runs.

Wayne Roseberry has 20 years experience working in the software industry. He is currently employed as a software test lead at Microsoft. Projects at Microsoft include MSN 1.0 – 2.0, Site Server and all releases of SharePoint from version 1 through 2010.

Test Automation has the potential to greatly increase the efficiency and effectiveness of a Test Team’s resources. However, it also has the potential to be a substantial drain on these same resources if not implemented strategically. It was with this in mind, that we set out to utilize test automation in order to boost the efficiency of our software testing effort, increase the quality of product, support the development effort and meet our on-time delivery requirements. The following paper is a case study that describes our journey towards developing and implementing our department’s first automated test suite.

I will describe the decisions and actions that we took along the way, including considerations of what to automate, how we determined the approach and an explanation of the life cycle of our pilot test automation project. From there, I will explain the transition that took place as our automation project progressed into what it is today: useful both as a testing and development tool.
This will include observations of the input/output trends that we have noted throughout the endeavor, how we verified our effectiveness, and how we overcame obstacles we encountered.

David Paul works as a Test Engineer for Vertex Business Services. David earned his Bachelor’s Degree in Computer Engineering with a minor in Computer Science from Oregon State University.

One of the primary goals of every developer should be to prevent or drastically limit the number of bugs or defects from being introduced in their source code. It is also our responsibility to write good, extensible, testable and maintainable code. This however seems like a herculean task to many. There is a wide array of metrics tools for your projects that can be run, such as code coverage, complexity, coupling, bugs, tests, suspicious code, style violations, copy/paste detectors, performance measurements, dependency analysis and more. Running these tools every time we write code becomes a nightmare. However, there is an easy solution for all this.

This paper presentation shows how to integrate all these tools with your IDE. If that isn’t sufficient, the paper also shows how to automate these tools to run them using a Continuous Integration (CI) server. Once these tools are automated and integrated with the CI Server, it can be a struggle to get a single, simple view of the project, and, even more importantly, how the project’s metrics are changing over time. Also covered in this paper presentation is how to create a simple dashboard which can produce a single page view of all these metrics, including trending graphs and analysis of the entire codebase.

Meera Subbarao works as a Senior Software Consultant for Cigital, Inc., which specializes in software security and quality. Meera has eighteen years of software programming experience. Prior to joining Cigital, Meera was a Senior Software Consultant for Stelligent, where she helped customers create production-ready software using Agile practices. She is a Sun Certified Java Programmer as well as a Sun Certified Web Component Developer. Meera has articles published regularly in online publications and frequently speaks at conferences like SD West 2009 and Software Test and Performance Conference.

The task of writing bug reports is a familiar one for software testers. Testers see an error message or witness unacceptable behavior in an application and create bug reports in their bug report-tracking tool. But is that error message the real bug or was the code written to indicate something went wrong? What about slow performance of a web page loading based on one input? Is the input the bug? Is the reaction from the application due to the input or a bug?

This presentation will not only address general testing practices in finding bugs, but testers will learn to mine the bounty and dig deeper. Go beyond the symptoms like error messages and explore behavior patterns to discover gold mines of information. Molly & Jean Ann will expand on the many benefits when software testing resources are dedicated to providing more descriptive information about the problems to Development. Attendees will learn how to recognize symptoms and be shown testing techniques in exposing root causes of bugs.

Real life situations will be shared with attendees along with step by step exercises to expand attendees’ skill set. When an error condition exists, Molly & Jean Ann will not only repeat the steps to confirm repeatability but also explain what kinds of other variables can be added or detracted to those steps to expose more information about the behavior. Why did one error appear when steps 1, 2, 3, 4 and 5 were implemented but the error did not appear when steps 1, 3, 4 and 5 were implemented?

Finally what knowledge does a gold mining bug reporter need to be successful? Throughout the session, Molly & Jean Ann will use personality traits and helpful technical skills to further expand upon the golden nuggets of bug reporting capabilities.

Jean Ann Harrison is a Lead Quality Assurance Engineer at CardioNet, Inc providing ambulatory cardiac monitoring service for physicians’ patients. Jean Ann is currently the software quality assurance lead on the next generation mobile heart monitor device and has been the lead on all embedded software testing at CardioNet. Jean Ann’s background also includes a variety of projects of large multi-configured applications for client/server, web, Unix and mainframe systems. Her experience is primarily manual testing with occasional automation and a strong focus on building quality into design. Constantly working to perfect her craft, Jean Ann attends and presents at conferences, takes courses, networks and actively participates in software testing forums. She believes software testing takes daily practice to contribute to a project’s success.

The scrum process was developed for teams that handle the different functions of software product development as one organization. With the scope and size of products growing, these pieces are handled by distinct teams. It becomes imperative to understand how scrum processes can be tailored to best fit individual validation teams, which are primarily consumers of the deliverables from by the development teams. This paper talks about the best-known methods indentified during the adoption of scrum by product validation teams. It provides a list of suggested tools, processes and communication mechanisms to maximize the benefits of scrum.

Results/Impacts and Lessons Learned:
Scrum is very effective; it worked very well for us. Here are some team specific things that can work as best known methods for other software validation teams.

• Scrum encouraged frequent communication between Dev and QA teams. Although our teams were interacting even before we adopted Scrum, the two-week Sprint cycle forced individuals to interact on a daily basis.
• Adopting Scrum helped the organization in identifying the issues that existed in the way our team worked with external teams; where we constantly were in a fire-fighting mode to work with newer hardware, firmware and platform drivers. Scrum did not solve these issues for us, but helped surface many of these at an organizational level.
• Shorter sprint cycles helped us acknowledge the number of interrupts that the team was dealing with that affected planned deliverables; it also helped better identify external dependencies.
• Physical task boards worked extremely well for our teams since most of the team members were co-located. The daily face-to-face stand-ups acted as a forum for regular intra-team communication. The two-week long Sprint goals on the task board helped keep the team focused on the immediate team goals, while the Product backlog focused on the longer-term goals to be achieved.
• The team received intact training and was encouraged to follow all of the key scrum methodologies for at least 3 weeks.

Mitali Monalisa is a software engineer with eight years of industry experience. She has been with Intel since 2005 in various roles of implementing and leading software projects.

Bhargavi Srivathsan is a validation technical lead in the Platform Architecture and Software Engineering group at Intel. She has functioned as a technical lead on multiple products, leads the validation technical review board, acts as the validation security lead and partners with the Security Center of Excellence (SeCoE).

The Extreme Programming (XP) software development methodology relies heavily on the co-location of the team members. The Extreme Programming team, according to the originator Kent Beck, should sit close to one another in an open environment where the whole team is able to see each other. This enables easy face-to-face communication between team members, which in turn improves team awareness, the team’s knowledge management and the social atmosphere. Nowadays, outsourcing and teleworking is becoming more common, meaning that XP practitioners need to adapt their daily XP practices for a distributed setting. XP in a distributed setting is called Distributed Extreme Programming. Research on Distributed Extreme Programming (DXP) is growing but is still relatively scarce compared to research on XP itself. In most cases the distributed XP teams have their own interpretation of DXP. These teams use (existing) tools that are a direct translation of a practice without taking into consideration that the practice may work better in a distributed environment in an adapted version. Other problems, which are mostly not tackled, are time zone or cultural differences. The social aspect, one of the key characteristics of XP, is also almost completely ignored most of the time. There is evidence, however, that upholding to certain graphical rules and functional flows will have a positive effect on the social feeling a person has with software. This means that software users can have a positive social state towards a tool, making it ideal to incorporate these types of rules in a DXP tool.

The Virtual Extreme Programming Workbench is a proposed tool that incorporates the Extreme Programming practices for a distributed environment and adheres to the XP philosophy of being social.

The social aspect of the VXPW and tackling the problems distributed XP practitioners face will have a positive effect on the software quality the DXP teams produce.

Richard Nieuwenhuis started his academic career at the Utrecht University where he finished his master’s degree in Software Technology in the beginning of 2006. After two years of employment as a Java application developer, Richard currently is employed at an interactive media bureau where he is responsible for the corporate online applications. For over a year Richard has been involved part time with the Open University for his PHD research. In his research, Richard tries to find a suitable adaptation of the Extreme Programming software development methodology for distributed environments.

The size of a test suite for a given functionality increases with introduction of test files. Often, test files are introduced without considering the redundancy they add in terms of code coverage. It is possible that we may get similar code coverage with a smaller set of files.

The codebase may contain a large number of ‘points’ of code coverage that are touched during the execution of the code. Also, the test suite itself may contain a large number of test cases – each exercising a different set of code coverage points. We describe a technique that enables us to find the smallest subset of test cases that exercises the exact same set of code coverage points as the test suite itself. We also demonstrate a prototype of this application that uses code coverage data supplied by a commercially available code coverage tool.

The immediate benefits of such an exercise are:

1. One of our test-suites was reduced down to 133 files from their original size of 600 files (down by 78%).
2. Developers may use the smaller set to quickly test their new changes.
3. Increase in productivity: Regular regression tests takes less time
4. Fuzzing for security: Provides a better starting point for fuzzing.

Subset can be identified based on multiple criteria:

1. Test Case Count
2. Time Taken to execute test cases
3. Input Size of test data

Rohit Kulshreshtha is a Member of Technical Staff at Adobe Systems (Noida, India). He is a developer in CoreTech – a team that creates shared components that form the building blocks of most of Adobe’s products. Rohit has worked on several key performance enhancements in PDF creation workflow. He has also been responsible for designing innovative architectures for components. Rohit is a member of the “Tiger Security Team” responsible for performing security reviews of CoreTech components. Rohit takes a keen interest in helping improve quality processes. Prior to joining Adobe, Rohit worked as an independent freelancer.

Complex software systems are no longer confined to the business and professional realms. As systems have become integrated into our daily lives, the need for simplicity is often in inverse proportion to the “behind the scenes” complexity.

Software users have become increasingly sophisticated in their requirements for functionality, while at the same time demanding more of the non-functional requirements; the ‘ilities’. It is no longer sufficient to just test the software. Test engineers must be business and end user focused as well as technically proficient in order to meet the demands of the users, the developers and the stakeholders.

This paper explores the evolution of the role of a test engineer from its emergence as a distinct discipline. By exploring the relationship between increased user sophistication, emerging hardware and software technologies, and development methodologies, the reader will understand how and why the role has evolved into one of a more holistic ‘quality professional’ and the opportunities and challenges that this expanded role presents.

Becki Bloch has over 20 years of experience in the software industry. She has held positions as an application developer, systems programmer, Test Engineer and Quality Control Manager. In her current position as a Senior Test Engineer at Vertex Business Systems, she performs a variety of roles from business analyst, solution lead, test lead and tester. Becki is a certified scrum master and recently obtained a degree in Web Development. She is passionate about software testing, working collaboratively with team members and clients and continuing to learn and positively influence the quality of software solutions developed at Vertex.

Test automation poses many challenges. The automation tools and framework need to be robust to ensure that tests are executed in a timely manner and results are accurate. The choice of automation tools is important. UI-based tools are useful to test the end-user experience and execute functionality not testable through the back-end, but may be slow and error-prone. Internally developed back-end tools are useful to test underlying functionality and are robust to UI changes and unexpected errors, but need to be thoroughly tested and maintained to ensure they test all required functionality and report accurate results. Successfully automating a test suite requires determining which automation tool is most appropriate for each test case, and ensuring that the testing tools are sufficiently accurate and robust to implement each test case. Seamlessly integrating automation tools and components and achieving full end-to-end automation present additional challenges. A final challenge is establishing best practices and coordinating efforts across multiple geographic locations.

This poster presents our experiences addressing these challenges in an end-to-end automation framework. Our framework includes a back-end automation tool (VTAF) developed internally using C#, and a widely used UI automation tool, QTP. Our framework integrates with MAGI, a company-wide test automation framework. The MAGI framework includes mechanisms to automatically launch tests on new builds, build the test rig, execute tests, and report results to a web server. The framework also includes a shared code base maintained by a core team and leveraged by all automation teams within the organization. We present an overview of the design of our automation framework and present the processes we established to implement this framework. We treat the entire automation framework as a product and follow a well-defined software process for developing and maintaining this product, including all of the following:

1. Automation auditing
   We established guidelines to determine which test cases are automatable and criteria to determine which automation tool (UI or back-end) is most appropriate for each test case. Many factors affect the preferred automation tool including the capabilities of each tool and the functionality being tested.

2. Code and script reviews
   All changes to the VTAF code are reviewed by other team members to ensure their accuracy and that best practices are being followed. In addition, test scripts are reviewed by other QA engineers to ensure that they match the required conditions of the original test case.
3. Documenting framework usage and best practices
   All requirements and best practices for test scripts and coding standards for the VTAF tools are documented and reviewed regularly by team members to ensure that everyone adheres to these practices.
4. Reporting and tracking framework bugs and enhancements in Bugzilla
   In our automation framework, our testing tools are products, and any defects or enhancements are assigned to team members to be resolved in a timely manner.

We present the design of our integrated automation framework and outline the details of each of these practices as we developed the framework. We summarize our experiences and lessons learned, and discuss future directions.

Laura Bright is a Senior QA Engineer at McAfee in Beaverton, Oregon where she specializes in test automation. She has worked in the area of software quality for several years. Previously she worked as a research associate at Portland State University where she specialized in scientific data management. She holds a BA degree from Dartmouth College & MS & PhD degrees in Computer Science from the University of Maryland at College Park.

Anand Iyer works as a Technical Specialist in McAfee at its India Center. Out of his 14 years of software industry experience, he spent the major part in ideating, designing & implementing solutions. He has worked in almost all phases of the SDLC assuming different roles each time including product documentation writer, project manager, test engineer & white-box tester. Anand prefers construction activities related to software testing, especially test automation. He has multiple whitepapers to his credit and has been a speaker at international conferences related to software testing.

Although touchscreens have been around for decades, their capabilities and prevalence are rapidly expanding. They’ve moved from huge, expensive, special-purpose business kiosks in airport terminals and banks to mobile devices that fit in our pockets and toddlers’ hands. They’re still used for business, but also for entertainment, games and phone calls.

As touchscreens move from niche markets to the mainstream, more testers will be testing software targeted at these devices. Test strategies based on physical buttons — on keyboards, mice and cellphones — need to be updated or replaced with new approaches that account for new interaction models and the variations in human hands.

This poster paper will highlight differences between traditional monitor/keyboard/mouse computers and mobile/touchscreen devices. Many of the issues discussed will be accompanied by hands-on examples. While the author provides examples based on her own experience Apple’s iPhone OS devices, the principles should be easily generalizable to mobile touchscreen devices.

Liz Marley tests the Omni Group’s Mac, iPhone and iPad productivity software. Liz has 7 years of professional testing experience, and 4 years of debugging homework assignments while earning a CS degree at Harvey Mudd College. Outside work, Liz accidentally finds bugs in knitting patterns and video games.