Software testers shouldn’t write code

Software testers shouldn’t write code. There I’ve said it.

“If you put too much emphasis on those [automated test] scripts, you won’t notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you’ll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else’s code.”

~ Joel Spolsky on testers

I used to think that you could/should teach testers to write code (as it will make them better testers), but I’m now at a point where I think that it’s a bad idea to teach testers to code for a number of reasons:

  1. A software tester’s primary responsibility/focus should always be to test software. By including a responsibility to also write code/software takes away from that primary focus. Testers will get into a trap of sorting out their own coding issues over doing their actual job.
  2. If a software tester wants their primary focus to be writing code, they should become a software programmer. A lot of testers want to learn coding not because they’ll be a better tester, but they want to earn more money. These testers should aim to be become programmers/developers if they want to code or think they can earn more money doing that.
  3. Developing automated tests should be done as part of developing the new/changed functionality (not separately). This has numerous benefits such as choosing the best level to test at (unit, integration etc.) at the right time. This means there isn’t a separate team lagging behind the development team for test coverage.
  4. Testers are great at providing input into automated test coverage but shouldn’t be responsible for creating that coverage. A tester working with a developer to create tests is a good way to get this done.

I think the software development industry would be a lot better if we had expectations on programmers to be responsible for self-tested code using automated tests, and testers to be responsible for testing the software and testing the the automated tests. Any tester wanting to code will move towards a programming job that allows them to do that and not try to change what is expected of them in their role.

Update 19th Jan 2015: this post seems to have triggered a lot of emotion, let me clarify some things:

  • A tester having technical skills isn’t bad: the more technical skills the tester has the better – if they can interrogate a database or run a sql trace then they’ll be more efficient/effective at their job – and a tester can be technical without knowing how to code
  • I don’t consider moving from testing into programming by any means the only form of career advancement: some testers hate coding and that’s fine, other’s love coding and I think it would be beneficial for them to become a programmer if they want to code more than they test.
  • I still believe everyone should take responsibility for their own career rather than expecting their employer/boss/industry leader/blogger to do it for them (more about this here).

Five organisations I would love to work for (geography aside)

I believe that it’s a good idea to keep a wish list of companies that you’d love to work for. This is not just to make sure you keep an eye out for opportunities at these companies, but also to discover what it is that makes you want to work at these companies. This makes it easier to chose other jobs that have some of those same qualities.

Your wish list also guides you to make decisions that open up opportunities at these companies, whether that talking to your work collegues about what it would be like to work there, or doing a LinkedIn search to see if anyone in your ‘network’ already works there.

Your wish list doesn’t even need to be realistic. None of the companies on my list are based in Brisbane, and only two are even based in Australia. I’m pretty much set on living in Brisbane; I love it for many reasons. The main reason is the proximity to my family and inlaws. At the moment, no job could be better than that.

But here’s my list:

  1. Threadless: I think this article pretty much sums it up. I also love this other quote about when they were deciding on how to make more money: We’re like, “we should give them stickers because stickers are awesome.”
  2. Atlassian: They make rock solid products (Confluence, JIRA…), aren’t afraid to take on the big players, and strongly support open source. I also love their mission and culture.
  3. Automattic: – Any wordpress user would know why I would love to work for Automattic. They advertise jobs such as Happiness Engineer and state that… everyone who joins Automattic, regardless of position, does support for 3 weeks.
  4. The Big Issue: Not only do The Big Issue support a great cause: homelessness in Australia, but the magazine is a really good read too. There’s no other mag that I enjoy reading more. This is truly a dream job though – they only have a full time staff of… three!
  5. 37Signals: Who wouldn’t want to work with the creators of ruby on rails and the authors of Getting Real? They also write one of my favourite blogs. But the real reason is that they really dig writing skills, and I dig that.

Software Testing Career Development

I am very interested in actively driving my own career in software testing. I believe that everyone should take responsibility for their own professional career development whether or not they get support from work to do so.

Ian Clatworthy recently shared his own professional development framework aptly named M.E.T.A. – Management, Engineering, Technology and Applications.

The framework is great in that it superbly breaks down technical professional development into four dimensions/pillars. The M.E.T.A. framework is probably better for software engineering so I have remixed it into something that suits my own software testing context better.


Leadership (Ian’s Management)


Whilst I have been in direct Management roles in the past, I currently do not work in one. I believe that it is important to demonstrate leadership no matter what role you are in. Even if your are not given the title Manager or Supervisor, or even if you don’t have people to manage, you can, and should, still demonstrate leadership. This is why I renamed Management to Leadership. For me Leadership is all about:

 

  • Using the right side of my brain – being organised, tidy & efficient (following concepts like 5S), being emotionally intelligent and aware, developing creative solutions.
  • Having a project management focus – following sound project management techniques and conducting each bit of work as a small project.
  • Writing Well – following known writing guidelines. Documenting every bit of work. Sharing all knowledge and information.
  • Communicating Well – Documenting well. Communicating progress and issues in the right format at the right time.
  • Team Building – establishing productive relationships with members of teams working in and with. I can’t emphasise how important this is.
  • Finding Informal Career Guiders – always indirectly looking out for people who you can chat to informally about career stuff. This is where I have discovered great leadership styles and techniques. I call these people career guiders because I really hate the word ‘mentor‘.
  • Being ethical – Making sure I provide value and I am honest in everything I do.
  • Sticking up for others you work with – Making sure that your fellow team mates are well supported.

Concepts (Ian’s Engineering)


I personally have chosen to focus more on the software part of software engineering. For me the Concepts pillar is all about the concepts and theories behind software design, development and testing. This is the stuff that I learnt at University and is generally timeless. For me Concepts is about ‘understanding’:

 

  • Understanding Software Development Methodologies: how IT software design and development works as a whole.
  • Understanding Software Projects: how IT software projects work.
  • Understanding Programming: knowing programming concepts and techniques.
  • Understanding Testing: understanding testing best practices, test driven development, test automation, acceptance testing.
  • Understanding User Centred Design: focusing on usability and designing for users. Paper prototyping and iterative design.
  • Understanding Design: understanding general design principles.

Tools (Ian’s Technology)


I was going to leave this called Technology but I ended up changing it to Tools as this is pillar is essentially the tools required enable the ‘Concepts’ above. These are different from concepts in that while most concepts are timeless, the tools or technologies tend to change.At present I am focusing on developing skills in using open source tools. I find these are good in that they are open and free (as in speech). Some tools I know and/or use are:

 

  • Programming Languages: such as Ruby, Python, Jython.
  • Testing Tools: such as Watir, OpenQA.org and homebrew test automation tools.
  • Collaboration Tools: such as wiki’s, defect management, blogs.
  • Versioning Tools: such as SVN, Git, Mercurial, Bazaar

I guess that one component to this pillar that doesn’t fit under the term tools are the technologies that are worth knowing about and understanding (perhaps I should call it Technology after all!). Things like:

  • Ajax (Rich Internet Applications)
  • Web 2.0
  • Social Networking
  • Tag-based Folksonomies
  • RSS

Business-focus (Ian’s Applications)


I believe it is important to understand the business of where you work, as well as the applications that support the business. Even open-source projects have business, they are in the business of providing software developed by communities of people to be used by other communities of people. I often see IT staff that do not have understanding or respect for the business. For me, displaying a business-focus means:

 

  • Understanding business goals: why I am employed in the first place.
  • Understanding business applications: what they do and how they fit into the business processes.
  • Understanding business processes: how business is conducted, with or without IT.
  • Understanding how business and IT collaborate and partnership: Hoping that the tail doesn’t wag the dog!
  • Providing value to the business: continuing to be employed.
  • Keeping up to date with the business: knowing what the business industry/competition is doing and about the other happenings in the business domain.
  • Understanding how executive management operates: because they usually pay you and maybe you would like to be there someday.

Conclusion
As Ian covers well in his post, the pillars make a great ordered list of dimensions in terms of career mobility. As I renamed his Applications pillar to my Business-focus pillar, I tend to consider my Business-focus pillar to be equally as or more important than my Tools pillar.

 

This means that my ordered list of dimensions is essentially Leadership, Concepts, Business-focus & Tools.

Like any contextual approach, everyone’s pillars will be different. This is a good thing. Although sometimes an unbalanced focus on a particular pillar can cause problems in your career. For example, focusing mostly on the Buiness-focus pillar may mean you can’t easily move jobs into a different organisation/industry when you want to.

What’s worse is not thinking about your career at all. Organisations may consciously develop their staff (as good managers do) but as staff are becoming increasingly mobile and contracted, the responsibility for career development is being pushed back upon the individual. This is when coming up with a personalised, balanced and ordered career development framework (and continually revisiting it) is so important.