Software Tester: experience first, formal skills then



  • There's a person with actual manual testing skills gained after countless testing of in-house software products [open that page, that page, and that page. Run test. Wait. Record results. Run performance test. Summarize. Gather artifacts. E-mail. Repeat to reproduce results.].

    Outside of that experience, that person is just a typical "install Ubuntu, learn to google shell commands" poweruser, and she asks us the developer people to give learning advice on QA road.

    As an actual software developer, who is going to keep an eye on that tester's skill progress - what practical skills, typically found in software developers, are most recommended to transfer to QA people to let them later find some work in that quality?

    Also, what skills should be never taught to testers by software devs?

    I recall hearing that Excel skills are much expect to prepare all kinds of statistical reports, are there other basics (probably never encountered by the poweruser) to be learned first?



  • As a manual/exploratory tester who works very closely with developers I find that the best way to improve my effectiveness is to learn as much as possible about programming in general, plus the languages/technologies (e.g. Drupal, WordPress) being used. Being able to code to the same standard as a developer is not a requirement to be an effective tester, but being able to hack stuff together or tweak existing code is definitely a good way to learn more about the products I'm testing and build up my overall domain knowledge.

    Being able to think about a product in terms of how it might have been coded also helps me to better assess risk, discover bugs more quickly and (often, but not always) identify a likely cause to an observed problem. I also find that having deeper domain knowledge helps me to write better bug reports that are written in a format that developers can easily understand.

    When testing front-end code, being fluent in HTML/CSS (with a good grounding in JavaScript) often enables me to pinpoint the section of code that is causing issues or needs more work. When I'm testing a website's back-end I'm generally not able to access the code that powers it, but having an understanding of databases, relationships between objects, user permissions etc. helps me to root out obscure bugs and get a good idea of what might be causing them.

    My advice to you (and the tester you're supporting), therefore, is to give him/her as much insight into how the software is built, for instance by explaining how key technologies work or by talking him/her through some of your code. This will hopefully help him/her to become a more investigative tester.

    I wouldn't say there's anything that a developer shouldn't teach a tester, but I do think it's important that testers aren't just replicating the testing already performed by developers. Testers need to be able to think beyond the code and the software's intended functionality; instead of just checking that things are working as they should, testers should use their intuition and creativity to find edge cases and unintended functionality that a developer might never have thought of.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2