Home · Certification · Job Board · Discussion Forum · Links · Membership · Next Meeting · Past Meetings · Steering Committee
 

New streaming content available for some presentations, we will be adding more.   Let us know how it works for you.  You need to have Java installed and enabled on your computer to playback.  Go to our FAQ page if you need help or have a question. 


Past Meetings 2008

    2008 · 2007 · 2006 · 2005 · 2004 · 2003 · 2002 · 2001 · 2000 · 1999 · 1998

 

EMULATION AS A TEST INFRASTRUCTURE

May 2008

Emulation tools are particularly suited to software development for embedded applications. Early emulators were based on hardware, limited in resources, and proprietary. They were poor tools to develop code, and just about useless for testing. Processor performance has improved tremendously and the situation is much better today. A prime reason is targets can now run a conventional desktop operating system. Dan will describe several important benefits from this for Development as well as Test, and what it takes to make infrastructure based on emulation workable. There will be a demonstration comparing emulator operation with the real target for a portable entertainment product. Emulation encourages automated test, and several examples will be shown.

 

Dan Voss, Varolii Corp

 

Dan has been involved in software projects for many years as a developer, project manager on small teams, and for the past 9 years, in testing.  Most of his experience is in embedded control applications that used emulation in some form.  This included test instrumentation at Fluke, computer system peripherals at Tally and Avocent, and most recently, wireless consumer products at Varia Mobile.  He just started in a quite different direction in database applications QA at Varolii Corp.  Dan earned a BSEE from Santa Clara University and an MSEE from the UW.  He has CSTE certification and is a registered EE in Washington

Software Load and Stress Testing

April 2008

Why does my perfectly working application crash and burn in  Production?  The reliance on Outsourced and 3rd party applications bring an even greater risk and need for Performance and Load testing. This presentation introduces the need and business justification for load/stress testing, walks through information needed in order to set up a successful test, and provides an overview of the tools and system monitoring tools needed.  Examples of real world impacts, typical performance bottlenecks, lessons learned, and success stories will be detailed.

PowerPoint Slides (54k)

 

Matt Kramer

Senior Program Manager for Boeing for the Scalability Test Lab
 

Matt Kramer has worked in Software Quality Assurance since 97 and has been in QA leadership since 99.  While in QA Management he has built two QA departments  from scratch being a single resource and expanding to a maximum of 15 staff with firm processes and a load test program.  Matt has worked in small start up's, at Microsoft, AT&T, and in medical information companies.  He has been running load and stress programs for Boeing programs for the past two years.

 

Lights Out Testing

 

March 2008

Testing approach for an ERP application is very different from that of a Custom built application. The ubiquity and the sheer scale of an ERP system along with the kind of business process knowledge it demands, make the Quality Assurance of the ERP system a highly complex flow. When operating within the constraints of time, effort and cost it is a really tough challenge to ensure the quality of the system at the highest level.

A strategy called the “Lights Out Testing” addresses these challenges and it works with the diligent use of automation in test execution and validation to improve the scope of testing and reduce the testing cycle time. The solution is a three pronged approach where it focuses on the Knowledge Management, the QA Process and Test Automation which can again be tackled in the forms of automated and configurable execution and validation.

PowerPoint Slides (2.8mb)

 

Danis Yadegar, President

Arsin Corporation

Danis has more than 25 years experience in all aspects of software design, development, and testing with special emphasis on integration, scalability testing, database, and user interface development and he has pioneered the development of testing strategies and test automation solutions for complex SAP implementations. Prior to Arsin Danis held various management positions at Hewlett Packard, Tandem Computer and Micro Focus. Danis holds a bachelor's degree in Computer Science, and attended graduate school at the University of Illinois, Urbana-Champaign

 

Combinatorial Analysis:

A pair-wise testing primer

February 2008

Fault analysis reveals that interaction between the variables of dependent parameters is a source of failure in complex systems. Imagine you are assigned to test a feature with 20 parameters that are interdependent. There are 5 possible variable states for each parameter. The total number of possible combinations is greater than a half trillion; which means that at one test per millisecond it would take more than 3000 years to test all possible combinations. Which combinations do we test? Pair-wise testing is a systematic procedure to effectively reduce the total number of tests by selecting a set of tests that evaluates every pair combination because historical and root cause analysis shows the majority of errors caused by the interaction of variables occurs between 2 parameters rather than interaction between the variables for 3 or more parameters. This talk compares orthogonal arrays to pair wise analysis, and then provides a detailed example of how to use one of the most powerful combinatorial analysis tools available today (Pair-wise Independent Combinatorial Testing, PICT) from Microsoft to systematically test complex interdependent parameters. Attendees will discover:

·         The difference between orthogonal arrays and combinatorial testing

·         How to logically decompose and model a feature set for combinatorial testing

·         How to customize a model file for smart combinatorial testing

·         How to use custom features of the PICT tool such as weighting, conditional and unconditional constraining, negative testing, seeding and output randomization

 

Bj Rollison, Test Architect, Microsoft, Inc.
  willro@microsoft.com Bj.Rollison@TestingMentor.com

Bj Rollison is a Test Architect with Microsoft’s Engineering Excellence group where he develops technical training curriculum, and teaches testers and developers at Microsoft various testing techniques and methodologies. Bj also teaches software testing courses at the University of Washington, and sits on the advisory boards for testing certificate programs at the University of Washington, the University of California Extension Santa Cruz, and Lake Washington Technical College, and is a frequent speaker at international software testing conferences

A Testers Guide to Aristotle’s Theory of Virtue:  A Model of the Happy Tester

January, 2008

 

This talk will introduce you to Aristotle’s (rather strict) Theory of Virtue, a theory that not only informs the Declaration of Independence but can guide the professional life of all testers. We will show how you can apply Aristotle’s principles to strategic decisions you may face as you choose to invest in emerging testing techniques and technologies.

 

Note: There were no slides... the presenter used the whiteboard.  Photos of the whiteboard are included in the On-Demand presentation.

  Michael Corning, Microsoft

Michael Corning  joined Microsoft in early 1997 a week after his first book, “Working with Active Server Pages” was published by Que. The book went on to smash records at Borders and stayed on the bestseller list for almost two years (10 months being an accomplishment in high technology publishing circles). He joined Microsoft’s Developer Support Group to help nurture the market for ASP. He recognized the potential of the next emerging technology, XML, in 1998, and in 1999, he joined the product team building Application Center to use XML to solve a perennial issue in Test: how can we keep test specs in sync with test code?

Email questions about SASQAG or this web site to webmaster at sasqag.org