Can testers assure quality? Part 1: if nurses were testers

Time and time again I bump into opinions, quotes, tweets and comments saying directly or indirectly testers are responsible for quality of software products. People who think so claim software error(s) that reach end user is testers’ fault and testers are the ones who can save the user. I strongly disagree with that.

Saying testers are (solely) responsible for software quality is same as saying a nurse is responsible for patient’s health before and after a sloppy operation.

I think this situation comes from the often used job title QA (Quality Assurance) and it’s variances: QA Engineer, QA tester, Quality Engineer, Quality Tester. Key word is assurance.

I especially like job title Quality Engineer as if there is Inferior or Poor-Quality Engineer. Quality Tester is a good one too, does he test quality or is it implied that there are Inferior Testers too? If job title is simply “tester” how did we end up tying it up to quality at all?

To some this assurance means simple bug hunting. In some radical examples developer slips through unfinished work on purpose hoping corner cases won’t be noted during business acceptance and won’t be encountered in production. Development process turns into hide and seek, cat and mouse game.

Continue reading “Can testers assure quality? Part 1: if nurses were testers”


Move Fast and Don’t Break Things by Ankit Mehta, Google

By a reference from a fellow quality engineer, I watched GTAC 2014 keynote video by Ankit Mehta on how different engineering and cultural practices help Google to move fast and NOT break things (almost). Overall Google’s test engineering goal is set to build an infrastructure and tooling to enable rapid launching of high quality innovative products that delight end users.

Continue reading “Move Fast and Don’t Break Things by Ankit Mehta, Google”

Cleaning up Bamboo Agents

If you have a problem of bamboo agents running out of space and wondering why build expiry doesn’t help you – welcome to the club 🙂
I too have bumped into this problem several times and naively thought that this is configurable via Bamboo Admin by Build Expiration setting. Still, our jobs would fail with “fatal: write error: No space left on device” quite too soon. Agent’s home folder was full and running Build Expiration manually with “133 builds affected” result didn’t help a bit. Still full. Most, like in 99%, of space being taken by checked out source code.
Continue reading “Cleaning up Bamboo Agents”

Did I do something good that day?

Did I do something good today?” – question I asked myself after a day of refactoring a long and repetitive test suite and ending up with TestSuite and TestSuiteOld. Was it a good time investment? Yes, I  did spend more time than I planned working with this 2500+ lines monster, but looking at our goals next time we would change this component wouldn’t be soon. The old suite worked just fine and now we have two files, different styles and a day spent not on testing new features or working on items from automation backlog (I’m a Quality Engineer a.k.a. Software Developer in Test). Was it worth it?

Gut feeling told me – yes, it was. First of all, I (finally) learned how this component works. More important, I’ve lighted a guiding light for creating less testing debt – tests for this component are now easier to create: common code is moved to setUp and private methods, tests are on average 7-15 lines shorter and work with data providers.

Few weeks ahead (surprise!) we need to change this exact component. Today on retrospective my team members told me they were happy that I managed to write several good cases that caught issues. All thanks to refactoring, it was so easy to create those tests that I was surprised it was mentioned. All I had to think is what data to put in new data providers. For me real issue was why it was me who caught these issues, but that’s another story.

Test/check automation code should be treated same way as production code (1, 2) and should be clean. It wil give you shorter cycle time, less bugs and happier team. To stop creating technical debt “Stop Writing Crappy Code“, stop it right now and write it good this time. It will pay of rather soon.

Messing with ffmpeg

Today evening I wanted to quicly upscale one SD video to HD with ffmpeg, which was my encoder of choice for quite a long time.

But it ain’t easy. First, default Ubuntu 12.04 ffmpeg didn’t support h264. Switching to VP8 didn’t help as output quality was awful and several how-tos had unsupported options. It all looked like ffmpeg was outdated. And it was. Ubuntu ships Libav, a fork of ffmpeg, v 0.8 w/o x264 support.

Luckly, there’s a ppa with latest version (0.10) of original ffmpeg on launchpad. Using

ffmpeg -i -acodec copy -vcodec libx264 -crf_max 7000 -q 50 -s 960×720

I could convert my 4:3 ratio SD file into 720p one. I wish I used Avidemux and hopefully it would just simply work.