Month: January 2018

Twitter pointed me to this link http://simplythetest.tumblr.com/post/169623787610/test-developers-arent-testers.  In this context, “test developer” means “person writing automated tests and/or infrastructure for automated tests”.

The author’s points are that these are 2 different roles, they have different mindsets, sometimes different objectives, and different skills. Some people can do both, or either, and that’s great, but some people in some organizations think they are interchangeable, and they are not.

Yes, true … but I think there’s more of a continuum than division. I found it interesting that the author seems to think that one person doing both roles is a small-organization thing. Well, I worked for a large-ish company, and when testers were assigned features, one of the deliverables was an automated regression test module for the feature, submitted to and accepted by the regression test team. There was a testing framework (homebrew, but with an actual dedicated support team), so most of the time, building that module was a pretty straightforward programming task. And if we needed something the framework didn’t support, we could make our own local edits to that framework while the framework support team worked on the needed enhancement or fix.

Maybe I see more continuum because of my experience? I’ve been testing telephony servers, and for that, even manual tests usually involve some sort of scripting because you need a tool to make the kind of phone calls you need. (Only occasionally is that tool a phone on your desk – and when it is, it is usually not the phone you use to order a pizza.) So the real question is how much automation is there – run a tool script directly, package the tool script in another script, make a script that both runs the tool script and checks the System Under test for results, or make a program that sets up your test environment and implements multiple test cases (run tool script and check results for each) and reports those results into an archive.

I love finding articles that make me think.

The January SQGNE talk was “Proactive Software Quality Assurance (SQA)™ Overcomes SQA’s “Traffic Cop” Resistance”. Interesting … I know that there are organizations where Devs view  SQA (under whatever name) as an obstacle, and I consider myself fortunate to have not worked for any of those.

For me, the useful thing about this talk was the reminder of all the trouble that comes from different definitions. Robin devoted quite a bit of his time to demonstrating that a roomful of software QA and test professionals produced a lot of different answers when asked to define “quality” and “quality assurance”.  I’m guessing that at a lot of companies one would get similar diversity of answers, asking the same questions of developers and QA and their managers, and that a little probing would expose some different expectations about what the QA people were supposed to do

“Done” is another word where different definitions can lead to problems. I remember a time long ago when a Dev I was working with declared that the application. was done Yes, I had done functional testing and he had checked in – but the application was not yet packaged so it could be installed, and it had no help text. So maybe he was done, but that application was not.

Remember to check definitions.

Resolution for 2018: get back into the habit of reading blog posts and articles about testing.  Starting today!

writing documentation for code

This makes some interesting points: (1) Naming practices are your first line of documentation (I knew that). (2)  Code comments that explain why something is being done are more likely to be useful than comments explaining what the code is doing. Usually the code itself is its own best explanation of “what”, unless the code is doing something obscure such as using an interface that is poorly or incorrectly documented. I think that’s a good guideline, although, thinking about test case automation, I think that may have more need for “what” type comments. If you have cause to assume that the maintenance on automated tests is likely to be done by junior people with limited understanding of both the product and the feature that just changed, then some code that is self-documenting for author-level experience may need explaining, and you may need comments to tie pieces of code back to test case steps – although possibly those could be considered as “why” type comments. (3) Unit tests are excellent documentation. I never thought of it that way, but Yes!