Blog Posts
Subscribe to the full blog feed using RSS
Interested in sponsoring the site? [find out more]
Subscribe to the full blog feed using RSS
Who doesn’t like looking at the innards of a web page and fiddling with it?
With most libraries you use to automate your work, you have to code workarounds. Here is a strategy for being informed when the workaround is no longer required.
TEST Magazine asked me to step in and write a quick answer to the question “As more organisations transition to an agile environment, how will the testers role be redefined?”.
An explanation of the Java Main method, and why we don’t really need it when automating.
March 2016 in London, at the SIGIST March 2016 Conference, I performed the closing keynote with a talk entitled"Push your technical testing further - into technology and security"
The slides have been released to slideshare:
The blurb read:
As testers we learn how to functionally test systems. We learn to analyse requirements and test ‘What’ a system should do. We can take our functional testing further. We can test ‘How’ the system does what it does, by understanding the technology used to build the system. We will find defects and issues that we would otherwise miss. Some of the defects would normally be associated with security testing, but we will find them without learning the techniques used for security testing. This approach to testing is applicable to any Software Development methodology and doable by any tester. Alan will explain the specific steps he used to learn to test web applications and push his functional testing further. He will provide examples of tools he uses, and why he uses those tools.
During the creation of Dear Evil Tester I posted a running commentary with information about the self publishing process. This post collates the smaller posts together in an edited format and acts as a primer of the self publishing process.
This is a mix of ’testing notes’ and ’thoughts on how to test’ this type of app. I spent about an hour or so looking at the app, so the notes are a little scrappy. I spent about 40 mins or so tidying them up for publication, in the hope that they help someone.
I attended the Tabara de Testare testing group on 3rd February 2015 to present “Lessons Learned When Automating. A live stream from UK to Romania.
The talk/webinar was drawn from questions submitted by the participants before hand, and from general experiences with automating.
The slides were designed to support offline study so should give a good feel for the content.
I’ve been asked some very challenging questions about lessons learned, and how decisions are made during the process of automating and performing technical testing. In this webinar I’m going to answer them based on my experience. We’ll discus how we know ‘what to automate’ which means we have to split our analysis into ‘detection’ and ’testing’. We’ll cover lessons learned from solving problems, and making mistakes, and steps we can take during the problem solving process e.g. for intermittent failures, and possible tool bugs. We’ll discuss abstraction levels and the different levels of the technology stack to automate: how to do it, and how we make the decisions. We’ll discuss coding primarily the differences, and the overlap, between the needs for coding for testing and coding for production deployment. We’ll also cover some WebDriver specific answers to some of these questions. I’m also going to describe books and techniques that have helped me over the years when trying to deal with these questions on production projects. Also we’ll take additional and follow up questions.
I found a feature I didn’t know about today in Firefox.
Stafford Beer was a famous Systems Theorist and Cybernetician and his books have influenced how I think.