I have added the slides for my TestWorksConf keynote to my TestWorksConf page. So if you’d like to see them then you can head off here. This post is to describe the rest of the conference and link to useful sources of information I think you’ll find interesting.
The conference (#testworksconf) was probably the most ‘hands on’ conference I have ever attended. Xebia, the organisers, created a usb stick with a VM which had all the software that would be used in the workshops and demonstrated by the speakers so that the conference attendees could hack along with the talks.
Because of the information provided at the conference, I have had my first exploration of Gatling. I was also able to spend some time with Erik Swets and he helped me use Gatling against Flood.io (which I was unaware of until Erik showed me).
Machiel van der Bijl pointed me towards a lot of Model Based Testing resources that I need to find time to investigate in more detail. During the conference Machiel provided a quick overview of Model Based Testing and demonstrated the tool that Axini have been working on.
Ivan Shubin provided a really good interactive demo of his Galen Framework visual testing tool. Galen has now bumped its way a little higher up my investigation todo list and I think is worth checking out.
John Smart provided the closing keynote with a demo of his Serenity tool, and more interesting the ‘Journey Pattern’ Actor approaches he uses to cut down on the amount of code in page objects and other abstraction layers. It was different enough from the type of approaches that I covered in my Abstractions talk that I need to look through John’s example code in more detail. Fortunately, John also used the TodoMVC app as his example target.
Also at the conference; an overview of updates to FitNesse, an intro to the Robot Framework and Cucumber.JS/Angular and Protractor. And a very interesting introduction to the Mox Angular mocking library.
Unfortunately there was too much on for me to go to every talk. A very interesting conference, very hands on, with lots to learn.
Hopefully I’ll be able to attend on future years as well.
I’ve been an automator and a test manager so I’ve experienced both sides of the coin, but I’ve always had the benefit of technical and programming knowledge and experience. So while I had an initial list of areas that I thought current managers working, or about to work, with automation would want to discuss, I wanted to see what would happen on the day.
At this point I’m working from memory without notes, because I was facilitating a discussion, so let’s see what I remember…
The Test Management Summit is a discussion based event, with the emphasis on the presenter moving to triggering and facilitating discussion rather than doing all the talking. As a result, when you look at the slides, the first half of the slides were designed for me to talk over, and the remainder held in reserve in case the discussion faltered.
In the event, I talked for 15 mins, and the discussion was lively and proceeded without requiring my reserve slides.
I made a distinction between use of tools, and automation. With automation having the characteristic of no manual intervention during its execution.
I emphasized the need to have an understanding of how the automation works. If you don’t understand how it works then you have added a dependency on your success on someone who does. This applies across the board:
If you use a commercial tool then you rely on the support team from the supplier
If you use open-source then you rely on the internet and the informal development team, but have the opportunity to involve yourself, if you have the skills
Similarly if you bring in frameworks or libraries into your automation, if you don’t have the skill sets to read, and possibly amend the code, then you limit the level that you can understand or fix them.
Regardless, we have to have some sort of way of deciding if the automation process supports your test approach, or not.
As to “Who can use automation?”. If you don’t have the skills to move beyond automation as ‘magic’ then you can only use it if an interface has been added to the automation which allows your skill level to engage with it. i.e. automation with one button to start it can be triggered by anyone, but if that is the level of your understanding then you won’t have the ability to intervene when something goes wrong.
This may, or may not, be managed as a risk in your organization.
Many people do not think through what they want from automation to identify if their approach to automation can meet their expectations, or to think through multiple approaches to achieving their aims. Too often we default to: “automate all the scripts”. I recommend thinking through where to buy propranolol online uk your aims, and identifying options. This will also help you work out if your automation ‘works’ i.e. helps you meet your aims.
Carl Dreher’s book is out of print, but I like it, as an historical overview of various forms of automation from mechanical devices through to cybernetics and computing. There are various quirks in language that I enjoyed, particularly the use of “Automationist” rather than “Automator” to describe someone who works on automation.
I also referenced “The Art of Leadership” by Captain S.W. Roskill. Another out of print book, but I can relate to the early sections in Roskill’s book where he describes two traits of military leaders that we don’t always expect from leaders in business:
An expectation that military leaders will train and teach as they gain experience
An expectation that military leaders need technical skills to ‘lead’ from the front and gain the respect of their troops
In order to balance this out for the business world, I think we make a distinction between ‘managers’ and ‘leaders’. Therefore managers may need to engage with automation in a different way than leaders who exhibit the traits above.
Should we convert manual scripts to automation scripts?
What would you do in the event of …
Single staff member having all the knowledge
Immediate “No – can’t be done” to requests for work
Staff who are ‘doing their job’ but are finished in half the day
How do you know your automation is working
How to recruit technical staff
What should a test manager do to improve their technical knowledge
What should a test programme manager do to improve their technical knowledge
Much of the discussion will remain private because it was provided by the participants themselves.
As add on points – during the discussion, I remember mentioning:
Use multiple layers of abstraction to support:
different “Who can use?” levels
use of automation in different ways, i.e. you can use the automation abstraction as a tool to support your testing, rather than only create non-manual intervention automation
Recruit with hands on exercises, i.e. pairing, discussion
Automating manual scripts does not lead to effective automation because
does not harness the ability for data driven automation (vary non-path invariant data)
does not harness the ability to use random data to explore assumptions inherent in equivalence class analysis
building on a point made by Adam Knight [http://www.a-sisyphean-task.com/] it does not encourage ‘alternative’ thinking about how automation can help test the system in ways that the script analysis did not identify e.g. API testing, adhoc automation to support defect investigation
Coaching without technical knowledge
Ask open questions of the team (i.e. non yes/no answers)
Ask “How can we…” questions
Encourage alternative investigations, but constrain them to time or scope
I confess to some nervousness about releasing the information since I don’t normally release the slides to tutorials and courses in case it cuts down on the value of running the tutorial or course again.
But, in this case, I don’t see enough information on the web about multiple Abstraction Layers and different ways of doing Page Objects, so I thought I’d throw my work out there, along with the supporting source code.
On a related note. I fronted a discussion at the Test Management Summit 2014 on Automation Abstractions. The slides for which were taken from the above presentation.
The aim for the slides and presentation is to demonstrate multiple approaches, so that people don’t just pick up the first ‘framework’ they see, or build ‘Page Objects’ without thinking through the modelling approaches open to them.
In the code and presentation I have examples of:
Page Objects that synchronize as slow loadable components
Navigation separate from Page Objects
DOM WebElement abstractions
The code and slides demonstrate some of my biases.
The main point is that ‘none of these approaches are best’, and we make decisions when we build our automation. We should take responsibility for those decisions and experiment with what works best in our environment, with our coding skills, with our development standards, for our application.
I’ll expand this material in the future. But I hope it helps somewhat in its current form.
You might also find the slides for my BDD tutorial relevant since I discuss some of my thoughts on BDD and Domain Specific Languages as Abstraction Layers.
I was a little nervous about this because of those 72 slides, 50 of them generic inderal form part of my Online course and I put a lot of material, detail, time and energy into them. But I now view them as something which might help people learn more about WebDriver. So I’m learning to let go.
We prepared a shed load of material, just in case no-one asked any questions.
Fortunately people did ask questions and the tutorial organised itself around the questions people had. We mostly managed to cover all the material we had. We didn’t get around to covering Page Object models in much depth and I don’t think we really covered domain models.
Fortunately, we released all the source code we produced in preparation on github, including the Page Object models and Domain Object models.