The Helix Nebula is 700 light-years away from Earth. The original image was taken by ESO’s VISTA Telescope.
I just finished the short but very powerful book A Briefer History of Time, by Stephen Hawking and Leonard Mlodinow. Space and how the universe works is something that has always fascinated me. I think it’s all the unanswered questions and the urge to understand what it ALL means, and the wonder of what may be out there.
A Briefer History of Time is a result of feedback about the original book A Brief History of Time in which many people requested a more accessible version. I for one am happy this was done as it’s now a great introduction to Hawking’s (and other’s) work which was relatively easy to grasp. Now that I have a taste for it, and a slightly better grasp, I’ll continue on and read his other works.
As I read non-fiction books I often think about lessons that can be misappropriated and applied to software testing. This wasn’t my specific goal while reading this book, but one that lingers in the background all the time. It’s often been discussed that testing can take many queues from science, and specifically the scientific method. I’m not going to try and put a new spin on this, but did have some ‘light bulb’ moments when reading this book that I wanted to share.
In recent times I have been heavily involved in hiring testers. This is includes fine tuning the hiring process, screening CV’s, interviews, take home exercises and so forth. It also includes spending time with recruiters. I have found two aspects of hiring interesting and we’ll look at one vital component of the process in this post.
I have found recruiters fall into two categories – those that listen and those that don’t. I have met some very good recruiters who have gone out of their way to build a rapport before trying to sell me their wares. I have appreciated this as I have found that they’ve listened to what we were after (our ‘requirements’ if you will) and we got to know each other better. This is important as testing (and the tech business) is about people after all. An example of this is when I recently spoke at a testing conference in Melbourne, Australia (ATD2K16) – three people from the same recruiting firm came to support me because we had established a very good relationship before hand!
I’ve just returned from Melbourne, where the inaugural Australia Testing Days 2016 (#ATD2k16) was held. I love these conferences. They are really what drives our community. In this case the TEAM Meetup Melbourne gave rise to the conference, which is new. Usually it’s the other way around, that smaller groups emerge from conferences. Nonetheless I thought it was a great success. People seemed to enjoy themselves and by the amount of participation I saw they were keenly interested too.
When I script large JMeter projects I immediately default to run scripts through config files. That means that all sorts of variables get pre loaded at the start of the test (VariablesFromCSV is a huge help!). From there I control things like URLs, usernames and passwords,… but I also control Thread Groups. Recently I came across the issue that I wanted to switch in such a config file between a test that ran for a certain length of time to a test that ran only X number of iterations.
For all of you that have used JMeter you know that that might be an issue.
For those that have missed this so far, take note that there will be a cool conference coming up in Melbourne with yours truly. My expectations are high for the 1st Australian Testing Days conferece. The lineup and topics look top notch. Have a look here: https://testengineeringalliance.com/australian-testing-days-2016/
If you decide to book use ERLEWEIN15 in the coupon section for a 15% conference discount.
I have been playing a bit with using WebDriver (Jmeter-plugins) from within JMeter. Usually something I abhorr but it does have the occasionto do was restarting the browser (Firefox) every thread loop. This ended up in a failure every time it tried to close the browser.
For years I have been thinking of open sourcing the work I do. I see the Blog here as a simple part of that effort. The main -selfish- reason though is, so I don’t have to carry code around from A to B and I can safeguard it from someone claiming it as their own (even me). Open sourcing is something easier said than done. Especially if things are over a certain size and the things I do are usually very tailored to the project context, which makes it difficult to generalise.
But… all things have to start small. I have released WinMinoTaur on GitHub today. These are just some small Windows batch files but they make test execution life with JMeter a bit easier. You no longer depend on the UI to execute tests.
…at least to some degree. Well, there are human conditions that distort the perception of time but it’s highly unlikely that you’re one of them. So you are a performance tester too.
The biggest annoyance for a performance tester is to get code into a performance environment that CLEARLY has issues that can be detected by the simplest means available (well.. second most annoying, as finding obvious functional defects is even worse). This is where you as a (whatever kind of) tester come in.
You know the times you drum your fingers on the desk waiting for that spinning wheel in the browser to come back? The batch job where the execution is exactly “making one cup of coffee” long? The usual response from you would be to shrug and say something like “This is just the environment. It’s system test afterall.” or “Let performance testing take care of it”.
Now, I can totally relate to such sentiments! We’re all busy and have deadlines to meet. I’d make the case though that you’d actually help the project as a whole and thereby yourself too by not ignoring such issues.
Somewhere I saw a statement that testing today is about 25% of IT budgets with a tendency to increase. Not sure if that’s true but even half of that is a lot of money. So of course managers and financial controllers are looking where they can eek out any spare $s.
Because testing and quality are not tangible or easily understood by outsiders it is tempting to cut and slash. There are no immediate or obvious down sides (50% of testing is still testing right?). Issues appear later and then the correlation back to the cause is spurious and it’s the operational budget then. And we all know testers are just all doom and gloom.
Now this one is a bit out there but maybe you’ll need this someday.
Sometimes clever developers put XML into table fields as BLOB or CLOB (well actually it’s a special BLOB just for XML so standard SQL won’t quite work as expected). Not sure why one would do that but not my place to comment. Anyway it’s a real pain if your holy grail is burried somewhere in that XML.So after some serious googling and trial and error I finally managed to do this in Groovy.