My partner is going to be testing software I've written. He handles the business side of things and isn't a programmer.
Can anyone suggest some resources for him to read to how to best touch our software?
Ask HN: Resources for learning manual software testing?
1–10 of 46 posts
Re: Ask HN: Resources for learning manual software testing?
#2A good start would be the ISTQB foundation level syllabus. While the ISTQB seem to be a litte outdated in terms of their views on the software development process: A focus on sequential waterfall-like models - it is a good resource to learn the vocabulary of software testing. Furthermore it explains different types and stages of software testing: http://www.istqb.org/downloads/viewdownload/16/15.html
Re: Ask HN: Resources for learning manual software testing?
#3Hmmm. I think you're looking at this the wrong way: it is not he who should be learning more about manual testing, it is you who needs to learn about how to write manual tests.
Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output.
What you end up with is a document containing dozens of pages full of small tables with test specifications, somewhat like [1].
So, to sum it up, it is you who should be doing the hard work of finding out what to test. You make a document full of tests which are as specific as possible, and let your partner walk through it. He doesn't understand what to do? Then you failed at being specific. He cannot find the functionality you ask for? Either a usability issue, or once again, not specific enough.
Hope this helps you somewhat!
[1] http://www.polarion.com/products/screenshots2011/test-specif...
Re: Ask HN: Resources for learning manual software testing?
#4I think something that drove it home for me is an actual written test script at my first part time job (before university). I was testing a tool called Internet Call Manager (if you used dialup and received a call while on the internet, this software would pop up a notification on your screen and allow you to decide whether to ignore the call or to take it).
Basically it was a table with the left hand columns being the instructions to perform, in point form, and the definitions of the expected/correct behavior, and the right hand columns being checkboxes and blank spaces to write in, indicating whether the software performed correctly.
It was super clear and to the point, and it was just a document that could be easily updated (and was, I believe I later made some modifications to the script when new versions of the software came out, but it was so long ago that maybe someone else was the one to do it).
Maybe you could write one of those up and he'd get a better idea for what his job was, and you could run through it with him a few times. After he gets the hang of it, I think it will have some value outside of just testing the code: he may come to understand how changes in one part of the code bring up issues in unexpected places (and get an intuitive grasp for, say, code reuse); he will be a true expert on the product (I've always noticed that QA people are often better versed in software than the assigned Product Manager, come demo time); and perhaps he'll start to grasp at a more physical level what your work actually entails, and it'll help give him context for software development as a process.
--
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.... Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […] The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be." - Fred Brooks
Let him learn some of the magic behind the poetry :) To your whole idea (biz/product guy getting hands dirty with product work), hear hear, bravo, etc.
Re: Ask HN: Resources for learning manual software testing?
#5Hmmm. I think you're looking at this the wrong way: it is not he who should be learning more about manual testing, it is you who needs to learn about how to write manual tests. Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output. What you end up with is…
Totally agree. Though the "[t]hen you failed at being specific" may be a tad harsh for my taste :)
Can iterate on the test spec/script, like anything else... and at the beginning the doc may even prove to be a great tool for contrasting baseline context between different people/roles/backgrounds.
Re: Ask HN: Resources for learning manual software testing?
#6Hmmm. I think you're looking at this the wrong way: it is not he who should be learning more about manual testing, it is you who needs to learn about how to write manual tests. Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output. What you end up with is…
Totally agree. Though the "[t]hen you failed at being specific" may be a tad harsh for my taste :) Can iterate on the test spec/script, like anything else... and at the beginning the doc may even prove to be a great tool for contrasting baseline context between different people/roles/backgrounds.
Yeah I know, it was more the kind of point you need to take with this. It is similar in spirit to "the customer is always right" -- of course that's too harsh, but it gets the point across. :)
Re: Ask HN: Resources for learning manual software testing?
#7Earlier quoted context omitted.
Totally agree. Though the "[t]hen you failed at being specific" may be a tad harsh for my taste :) Can iterate on the test spec/script, like anything else... and at the beginning the doc may even prove to be a great tool for contrasting baseline context between different people/roles/backgrounds.
Yeah I know, it was more the kind of point you need to take with this. It is similar in spirit to "the customer is always right" -- of course that's too harsh, but it gets the point across. :)
Truth be told, I totally agree with your sentiment - if the test spec is unclear to the guy executing it, something needs to be changed... just reflective of the direction I've been trying to take my attitudes and my language; I even have a git alias "an", short for annotate, which performs the "blame" command :D ("git-blame - Show what revision and author last modified each line of a file")
Re: Ask HN: Resources for learning manual software testing?
#8Give uTest a try, you can participate in crowd-sourced test cycles and gain both experience and money.
And they have really cool resources over here: https://university.utest.com
Re: Ask HN: Resources for learning manual software testing?
#9A good start would be the ISTQB foundation level syllabus. While the ISTQB seem to be a litte outdated in terms of their views on the software development process: A focus on sequential waterfall-like models - it is a good resource to learn the vocabulary of software testing. Furthermore it explains different types and stages of software testing: http://www.istqb.org/downloads/viewdownload/16/15.html
Yes, this is a real problem! I learned testing in a waterfall environment (basically followed IEEE standards, ISQTB processes) and now work at a company that is more Agile. So many of the skills/techniques are fundamentally incompatible.
Re: Ask HN: Resources for learning manual software testing?
#10Hmmm. I think you're looking at this the wrong way: it is not he who should be learning more about manual testing, it is you who needs to learn about how to write manual tests. Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output. What you end up with is…
Ahh, this is the kind of thinking that frustrated me in my time as a software tester.
From a functionality perspective: maybe, but if the developer needs to explain the intended functionality of the application to the business end of the product then something has gone horribly wrong.
From a sheer "finding bugs" perspective: If you knew what would actually expose buggy functionality to the extent that you could write it down, you wouldn't have written that in the first place!
I encourage you to teach him the way that your specific language makes things happen on the machine and the way that software in general works (boundary conditions, etc). But I don't think that the above way of doing things, ESPECIALLY for a 2 man outfit, is a good idea.