Thoughts on Performance Testing in NZ
I’ve spent the last couple of years helping projects with their application performance in NZ (mainly Wellington). I thought it’s about time I wrote something on the experiences I’ve had during that time and the lessons learned.
NZ is comparatively a smallish place. 4.5m people live here. A large bank for example has about 0.5-0.75m customers. One of the biggest online applications running in NZ is probably TradeMe. They have 2.8m customers and about 75k-200k active customers at any point in time. On average they have less than 1m logins a day. If I contrast that to large international systems this is laughable. Ebay for instance has 83m users and 670 million page views a day (I don’t know from when these figures are though). Facebook has 750m users,…. So big international companies talk about building another datacenter, where we might start clustering.
We do things a bit smaller. That has its advantages – if we do our homework correctly. Most products used nowadays are designed to be massively scalable to the requirements of large international companies. So we should have no issues with performance….EVER!
But as you probably know from your own surfing experience this is not always the case. It gets even worse when we use web applications that are in-house. All of this should actually be a no-brainer. So what’s going wrong?
I’ll try and list the thoughts and experiences that I see are common in projects here (no particular order).
Beyond scripts – transcripts
“Can you show me your test scripts?”
“Will your test scripts be part of the deliverable?”
“This role involves writing and executing test scripts”.
There is a sector of the software development community that believes, no, accepts unquestionably as a truth, that testing is writing test scripts then executing them. This leads to a vicious cycle of managers and clients asking for test scripts, and testers delivering test scripts because they were asked for them, thus reinforcing the requests and so on ad infinitum.
Read more…
Thanks Steve
A little on the late side but I did want to do a post on thanking Steve Jobs and what he did for me personally.
I’ve wanted an Apple ever since the original Apple II. My first Mac I ever saw was actually an Apple Lisa at my fathers design department. They were using it for CAD with a whopping 5MB Winchester drive. But the world turned out a bit differently. I never got to having an Apple II or a Mac.
Only in 2004, when we immigrated to NZ did we shell out for a MacMini and enter Steve’s world. Today we own several Macs, have had many more, have iPhones, iPods and are 101% Apple followers. We’ve never looked back.
But what has that got to do with a testing?
As it turns out there is/was someone at Apple which had a relentless drive for quality and usability. Now as you can easily guess that person is/was Steve Jobs (still struggling with the was here!). This drive is pervasive in all Apple products.
Did you enjoy STANZ 2011 in Wellington?
Our first Defect
So we had our first defect raised. On the Chrome browser the RSS link above right doesn’t seem to work and complains about a missing style sheet. I’ve tested it on IE8, FF4 and Safari and all work just fine. So I’ll just put this down to “Google….get that fixed!” ;-)
So sorry guys, if you want the RSS on Chrome, use something else for now.
But apart from that can I say I just love the testing community!!! You actually get feedback. Feedback is the only and -in my opinion- best way to learn. As a tester it’s what we do. We just put our foot in it wherever we can. I try and train my skills wherever I am so I of use feedback buttons on websites and do report issues with software. And the amazing thing is, that it works. Things do get fixed and companies, OSS projects, web masters,… they do react and they gladly do so.
So if you’re out there and see something you don’t like. Don’t click to the next page. Complain, rant, feed back but remember always to be rational, explain in detail and state the context. You will see that it works and that you’ll have trained your skills.
Author: Oliver
ISTQB: Possum Certification
Repost from http://testerkiwi.blogspot.com/
In my last post, I talked about the concept of possum testing: Doing testing-related activities that the tester does not value, motivated on some level by fear. I’d like to extend this concept out, and talk about the fundamental problem I have with ISTQB certification: It’s a possum certification.
If possum testing is testing that the tester does not value, motivated on some level by fear, then possum certification is the acquisition of certification that the receiver does not value, and the attainment of that certification is motivated at some level by fear.
ISTQB rely on deceiving their customers that what they will be getting is a valid qualification. They have successfully created a vicious cycle where employers believe that ISTQB certification is somehow some kind of valid measure of a tester’s skill so they ask for it in their job ads. Prospective employees see it in the job ads, and therefore think it must be a valid qualification, after all, look at all these companies asking for it, so they go out and get it. Employers see employees with it on their CV, and thus confirm in their minds that ISTQB certification is a valid certification, after all, look at all these applicants with it on their CVs. And on the cycle goes. Meanwhile, ISTQB do nothing to correct the situation. But why would they?
I can only conclude that the ISTQB is deliberately exploiting the fearful, at the point in their careers when they are the most vulnerable. Instead of helping possums cross the road safely, they are creating a deception in the industry. The name itself “International Software Testing Qualifications Board” has been deliberately constructed to dazzle employers into thinking it is somehow an official industry board. They are taking our craft, and diluting it into a three day dictionary definition course, and passing it off as a legitimate qualification. They are stifling innovation and critical thinking by indoctrinating new recruits into the field with “best practices” and definitions that don’t even hold up to a moment’s critical analysis.
They are making money off the fear of new testers, who fear that they aren’t employable without certification, and the ignorance of employers who don’t understand the field. They perpetuate the ignorance by giving themselves an official sounding name that implies universal acceptance and authority.
To me, it is wrong for ISTQB to be intentionally misleading employers, and exploiting the fear of newbie possums. If you feel the same way then speak out, and stop letting this ruining our profession. Stop the spread of folklore and myth that the ISTQB syllabus teaches, and perhaps we can take back our profession from those who seek to only profit from it, rather than study it.
Author: Aaron Hodder
ISO 29119 the “new” testing standard
On Tuesday night, Steve Willsher (QualIT) gave his best to bring ISO/IEC 29119 closer to our testing hearts at a NZCS TPN presentation. Kudos for him to really have a go at the beast that is standardisation. I am part of the working group and am at least familiar with the documents being produced. The thing is that I’m not (yet?) sold on standardization in testing and IT in general, where the intent is that it applies everywhere. In this post I’d like to share some of my concerns and elicit some debate on the topic.
The first thing I’d like to highlight is the way a standard is “born” (note the use of quotation marks here, as in the title around the word – new.) All going well ISO 29119 as a standard will be released, at it’s earliest, May 2013. This will be after already being on a 2 year journey involving lots of groups, discussions and opinions. In the last 5 years I have seen quite a few revolutions/evolutions in testing and IT SDLC in general. Testing, and IT, is still in it’s infancy and new ideas are cropping up daily, so it eludes me how the standardisation process is not being overrun by current events. The risk of the standard being out of date when it gets released is immense. The timelines for standardization might be okay for other engineering disciplines but IT moves at a faster pace (also accelerating other fields but not quite to this speed). I think the process is too unwieldy.
Hello Test World!
Hello all to this new testing Blog of Aaron Hodder, Brian Osman, Oliver Erlewein and Richard Robinson. Some of us have our own testing blogs but the thought here is that, since we think along the same lines and together seem to pack more testing-punch, it is natural for us to meld our minds into one blog. Our hope it is that you will be the main beneficiary of this and we can help you reflect and learn new things as you progress in your testing career and the profession in general.
You will also see our twitter streams at the bottom and rhs of this blog so follow us to stay on top of things.
Since STANZ 2011 is on next week in Wellington we’re rushing a bit to get this blog out the door and start reflecting on what’s happening in the scene. So please check back regularly to see new stuff.
