by Sean Robbins
Thursday the 25th of August, was the second ever Software Testing Club Meetup I have attended and it just so happens that this is one that I organised in Cardiff. My friend Andrew Morton, @testingchef, has written his own write up of the event on his blog. As the organiser of the event and because I felt I came away with a slightly different perspective from the event, I thought I’d offer my own thoughts.
Lightning Talks
There were four lightning talks on the night, the first of which I did myself, @sean_robbins. I took what I hoped might be recognisable automated test, the Google Search automated test often used to try out automation tools.
I took this straightforward automated test and using Watir-Webdriver and Mechanize, I implemented it 3 different ways.
My point was that for any given automated test actually thinking about what it is you want to verify can lead to better test design. I intend to write up the talk as a separate blog post so will go into more depth on this soon.
The second lightning talk was given by Warren Seymour, @woogoose, who is a developer and runs Fountainhead Solutions in Cardiff. Warren talked about adopting the Model-View-Controller architecture for JavaScript, to make frontend logic more testable. He suggested developers try out tools like JavaScriptMVC and Backbone.js to investigate this approach.
The third talk was from Vicky Dibble who talked about Performance Testing. She discussed defining clearer performance requirements and selecting which user scenarios to test. She also discussed defining these scenarios using UCML (User Community Mark-up Language), which I wasn’t familiar with but will definitely be looking into more.
Last but not least, was Mark Coakley from Admiral, who discussed the regression testing for a large legacy application and ensuring that existing documentation and test cases are relevant enough to use for training new staff members. Perhaps of more interest to me however, was the illustration of the sheer challenge of testing a legacy application of that size and complexity.
My Takeaways
As much as I like the lightning talks and the social aspect meeting testers and developers from other companies, the main thing that I enjoy from these events is often the discussions that evolve after the talks.
In this case, I came to feel that my talk, Warren’s and Mark’s had complimented each other in a perhaps, surprising way. I had discussed test automation design but arguably with the assumption of a Greenfield project that requires GUI automation. Warren talked about reducing, and even argued for the removal, of the need for UI automation at all through improved code testability and developer testing. Thirdly, Mark’s discussion of an existing legacy application which I happen to know has some automation coverage.
I had with some developers where I was discussing how I’m not always sure, when automating a test at or just behind the UI, if it is necessarily the most efficient place for that particular test to be run.
There was some discussion if the UI is ever the most efficient layer to automate tests against and some instances were suggested by a developer, who suggested an application that might integrate with a number of services and execute a number code paths based on a single UI event. A literal request from the UI could very often prove to be the most efficient way to ensure that, all of the events that would be triggered by a real user event, have been exercised. The other example was large legacy applications, which may be unlikely to have been written to modern standards of code testability and TDD. I suspect that manual regression tests that are run against the UI frequently when supporting legacy applications whereas, much of the code may be touched fairly infrequently. In this case, creating UI automation from existing regression cases might be efficient, whilst gradually refactoring the code to support unit test coverage.
Warren was, in my opinion, right to say that we should be building applications so as to make them easier to test and work to make clear at what level we should be running identified test cases. That said, I wonder how much of the software testing industry are working with existing codebases that may not be in a position to adopt this approach. I also think that even applications built to have strong test coverage, will over their lifetime continue to become more complex and so in some cases GUI automation will become desirable.
Andrew reported on his write-up of the event that he had a discussion that automation is the big thing that companies are looking for. Although this may be true, I’ve taken the opinion that automation needs to and will perhaps inevitably be tailored to the needs of the application and environment where it is deployed. That is to say that as an industry we might need to realise that test automation implementation needs to be context-driven.
Software Testing Club Meetups
The Meetup events seem to gaining momentum with a number of them are planned over the coming months. If you haven’t already looked, I would encourage you to have a look to see if there is one happening near you by looking the Meetup page at http://www.meetup.com/SoftwareTestingClub/ . If there isn’t one planned near you, I’d definitely encourage you to consider organising one.
I want to thank everyone who came to the event especially the speakers and the sponsors – Box UK,http://www.boxuk.com/ and Opus Recruitment Solutions, http://www.opusrecruitmentsolutions.com/ particularly Samantha Miller, @samatopus, who specialises in tester recruitment.
About Sean Robbins
Sean Robbins is Head of QA at BoxUK, he is on Twitter as @sean_robbins and blogs (very) occasionally at http://testervations.blogspot.com and on the Box UK blog. He has a weird sense of humour and likes cheese.
No comments yet.