#AUTOMATION GAME WORKSHOP MANUAL#
#AUTOMATION GAME WORKSHOP SOFTWARE#
#AUTOMATION GAME WORKSHOP CODE#

ItвЂ™s a fascinating puzzle to solve вЂ“ we simulate real-world or error conditions, look at the data, find anomalies and investigate the root cause.

#AUTOMATION GAME WORKSHOP CODE#

As performance thought leaders like Scott Barber will tell you, performance testing is roughly 20% of the automation code development and load generation work, and 80% interpreting results and finding problem areas to address. Load and performance testing is a fascinating approach to test automation. We also have other types of automation to consider. However, you can get a lot of efficiency for testing at this level by cutting out the slow GUI, and we can explore the emergent properties of a system that we donвЂ™t see at the unit level.

People often prefer we look at the GUI, or the code level of automation.

#AUTOMATION GAME WORKSHOP SOFTWARE#

In the software testing world, we donвЂ™t have explicit rules against testing at this level, but we arenвЂ™t often rewarded for it either. In video or online games, some people use tools to help enhance their game play at this level, sometimes circumventing rules. There are integration paths and emergent properties that we can catch at this level that we will miss with unit testing, but by stripping the UI away, we can create tests that run faster, and track down intermittent or other bugs that might be masked by the GUI. The system context is a bit more rare, but we test machine to machine interaction, or simulate various messaging or user traffic by sending messages to machines without using the GUI. ( David McFadzean introduced this idea to me during a design session.) In video game design terms, we might call repetition that isnвЂ™t very engaging as вЂњ grindingвЂњ.

#AUTOMATION GAME WORKSHOP MANUAL#

We frequently look to automate away the repetition of manual testing. The software has emergent properties by combining code, system and user expectations and needs at this level. In this context, we are concerned that the software works reasonably well for end users in the places that they use it, which are social situations. In other words, regression testing is often outsourced to a tool. People would rather get the tool to repeat the tests than deal with the repetition inherent in regression testing, so they use tools to try to automate that repetition. This approach of testing is usually dominated by regression testing. In the social context, we are concerned about automating the software from a userвЂ™s perspective, which means we are usually creating tests using libraries that drive a User Interface, or GUI. These kinds of tests are less about being rewarded for finding bugs вЂ“ вЂњCool! Discovery!вЂќ and more about providing a safety net for coding, which is a different high value activity that can hold our interest. WeвЂ™re concerned that our code works sufficiently well in this context. This type of test automation is usually carried out by programmers who write tests to check their code as they develop products, and to provide a safety net to detect changes and failures that might get introduced as the code base changes over the course of a release. In the code context, we are dominated now by automated unit tests written in some sort of xUnit framework. (Note: I first introduced this idea publicly in my keynote вЂњTest Automation: Why Context MattersвЂќ at the Alberta Workshop on Software Testing, May 2005) In each context, the automation approach, tools and styles differ. I look at three main contexts for test automation:Дў. In the test automation space, we have other approaches. Two dominant manual testing approaches to the software testing game are scripted and exploratory testing.

Automation game workshop