TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

43
Automate or Die! Alan Richardson EvilTester.com SeleniumSimplified.com JavaForTesters.com @EvilTester “Real World Automation Survival”

Transcript of TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Page 1: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Automate or Die!

Alan Richardson

EvilTester.comSeleniumSimplified.comJavaForTesters.com @EvilTester

“Real World Automation

Survival”

Page 2: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Can you

survive?

Challengers of the Unknown, DC Comics, #23, 1961

Page 3: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Automate or Slave!“Let us remember that the automatic machine ... is the precise economic equivalent of slave labor. Any labor which competes with slave labor must accept the economic conditions of slave labor. It is perfectly clear that this will produce an unemployment situation”

Norbert WeinerThe Human Use of Human Beings,

1950, pg 162

Page 4: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Don't compete with slave labour

Challengers of the Unknown, DC Comics, #33, 1963

Page 5: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

"...automation makes it possible to do many things

that could not be done without it..."

John Diebold,

Beyond Automation,

1964, pg 191

Page 6: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

Automating isn't easy

Challengers of the Unknown, DC Comics, #28, 1962

Page 7: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Automating has always been a challenge

Page 8: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Challengers of the Unknown, DC Comics, #18, 1961

Page 9: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

“Automation has turned out to be a much more complex and difficult problem than was

originally thought.”

John Diebold, Beyond Automation,

1964, pg 51

Page 10: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

“What we need is more automation.”

1948

Ford Motor company VP,

Delmar S. Harder,

Coined “automation” in 1948

Page 11: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

John Diebold,

“Automation”, 1952

"...the author found automatization both awkward and - from the standpoint of his weak spelling - hazardous ... it was the ease of spelling that finally overcame the author's reticence to coin a new word"

Page 12: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

1957

Page 13: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

The word “Automation” is...

“barbarous”

http://www.norbertwiener.umd.edu/NW/NWphotos.html

Norbert Wiener

Page 14: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester “Science”, May 6th, 1960 http://bit.ly/1iwga1m

Page 15: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester “Science”, May 6th, 1960

'automatization', 'automata', 'strategy','machine', 'automatic', 'automated', 'programming'

http://bit.ly/1iwga1m

Page 16: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Watch your language

Page 17: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Automation is not a 'thing'

Page 18: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

'Automation' is Arguable

'Automation' is vague enough that we can argue about it

Testers need to program to do

automation

Testers can do automation without needing to program

Page 19: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Abstractions

“... what we see, hear, feel, speak about or infer, is never it, but only our human abstraction about 'it'.”

The Role of Language in the Perceptual Process

Alfred Korzybski

1951http://bit.ly/1G06gL0

Page 20: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Testers need to program to write code that will automate this

scenario

Control your

specific language

Testers can identify the paths through the system that we

will automate without needing to program

Page 21: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Solutions not tools

Challengers of the Unknown, DC Comics, #18, 1961

Page 22: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

For 'tools' to be solutions, you have to know what

problem they solve

Page 23: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Challengers of the Unknown, DC Comics, #18, 1961

Page 24: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Automating Applications isn't easy

Challengers of the Unknown, DC Comics, #18, 1961

Page 25: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Automating is often a hunt for

workarounds

Challengers of the Unknown, DC Comics, #27, 1962

Page 26: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

How technical

do testers need to

become?Challengers of the Unknown, DC Comics, #20, 1961

Page 27: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

How can we observe and manipulate the system at

deeper levels?

Page 28: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Team skills are important

Challengers of the Unknown, DC Comics, #27, 1962

Page 29: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

BDD● BDD is not about testing● BDD is not about tools● BDD Tools are not testing tools

Page 30: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

“Whatever you might say something "is", it is not.”

Alfred Korzybsi,Science and Sanity,

1958, page 409

Page 31: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

BDD● BDD is not about testing● BDD is not about tools● BDD Tools are not testing tools

“If BDD tools aren't test tools why do we use them as part of our test approach?”

Page 32: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

I use Cucumber...● … as a tool for creating Domain Specific

Languages● … to easily document and implement data

driven scenarios

Page 33: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

A 'Test' tool is any tool you use when testing

Page 34: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

The solution to problems when automating is rarely

more automating

Challengers of the Unknown, DC Comics, #28, 1962

Page 35: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Abstraction Layers“We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called “abstraction””

The Humble Programmer

Edsger W. Dijkstra

ACM Turing Lecture 1972http://bit.ly/1MVghiP

Page 36: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

@Testpublic void canCreateAToDoWithNoAbstraction(){ driver.get(

"http://todomvc.com/architecture-examples/backbone/");

int originalNumberOfTodos = driver.findElements(By.cssSelector("ul#todo-list li"

)).size();

WebElement createTodo = driver.findElement(By.id("new-todo"));

createTodo.click(); createTodo.sendKeys("new task"); createTodo.sendKeys(Keys.ENTER);

assertThat(driver.findElement(By.id("filters")).isDisplayed(), is(true));

int newToDos = driver.findElements(By.cssSelector(

"ul#todo-list li")).size();

assertThat(newToDos, greaterThan(originalNumberOfTodos));

}

Page 37: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Abstraction Layers“... the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.”

The Humble Programmer

Edsger W. Dijkstra

ACM Turing Lecture 1972http://bit.ly/1MVghiP

Page 38: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

@Test public void canCreateAToDoWithAbstraction(){ TodoMVCUser user =

new TodoMVCUser(driver, new TodoMVCSite());

user.opensApplication().and(). createNewToDo("new task");

ApplicationPageFunctional page = new ApplicationPageFunctional(driver,

new TodoMVCSite());

assertThat( page.getCountOfTodoDoItems(), is(1));

assertThat( Page.isFooterVisible(), is(true));

}

Page 39: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Refactor to Abstraction Layers

● Physical● Logical● Domain● Data● Event● Actor

Page 40: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

And how do you find time to test when you

are automating so much?

Challengers of the Unknown, DC Comics, #18, 1961

Page 41: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

Survival is a way of thinking...

“Automation requires us to view the production processes as an integrated

system... Automation is a way of thinking, a way of 'looking at...' as much as it is a way of

doing... It is an attitude... rather than a particular technology”

John Diebold, Applied Automation. A Practical Approach,

p. 3 1955

Page 42: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

“Automation requires us to view the production processes as an integrated

system... Automation is a way of thinking, a way of 'looking at...' as much as it is a way of

doing... It is an attitude... rather than a particular technology”

John Diebold, Applied Automation. A Practical Approach,

p. 3 1955

Systems

Abstraction

Survival is a way of thinking...

Requisite Variety

Page 43: TestWorksConf 2015 Keynote Test Automation Conference Amsterdam

@EvilTester

“Automation requires us to view the production processes as an integrated

system... Automation is a way of thinking, a way of 'looking at...' as much as it is a way of

doing... It is an attitude... rather than a particular technology”

John Diebold, Applied Automation. A Practical Approach,

p. 3 1955

Requisite Variety

Systems

Abstractions

Survive