I've done a bit of software testing here and there.
At the basic level, you'll never see a single line of code. The programmers write a function, or an interface, or some other aspect of a program they're working on, and that becomes part of the current development version of the code. Sometimes there are separate chunks of code being worked on, sometimes it's all one big chunk. But you'll never see it directly; you'll just see the result of it when it runs.
Either way, you then generally have a setup where that current bit of code is made available to you as a tester. You then run the program or the chunk of code - the exact arrangement of how to do this depends on the job, and will be explained to you - and try to mess around with it to see if you can break it. Basically, the idea is that it's better that you break it (and the programmers figure out how and fix that) before it goes out to the customers or end-users and they break it.
The nitty-gritty of how to do this can vary. Some testing environments have semi-automated testing programs which will run the program and try different kinds of inputs to see if the results match up, and you may find yourself altering the parameters of those programs or writing new testing scripts. Other testing environments are more manual - you may be the one personally entering different information or screwing around with interface elements to see if they hold up under your rough treatment.
Actual examples of things which can be tested range from entering information when a program to be tested asks for it, and seeing if both valid information produces valid results, and invalid information is caught properly by the program. (Example: You are supposed to enter a number from 1 to 10. You might try entering 1, 9, 10, 11, 0, 5.5, 0.9, "5" as a text string instead of a number, "five" as a word, "5-", "-5", "5-0", "5.", " 5 ", "5 6 7", "" (blank entry), 256 fives in a row, 257 fives in a row, Unicode characters which look like numbers, and so on.) If you're doing advanced testing, where you get to see the code behind it all, you might be entering more esoteric things, like segments of SQL statements, which is more about trying to hack the program than test it.
Likewise, there are all kinds of other things to test. Does the program work on different platforms (desktop, mobile, tablet, etc?) Does it still work properly and have all the necessary elements visible/available if you reduce the window down to a tiny size, or up to thousands of pixels across? Does it work if the operating system is shrinking or expanding the size it displays text in, or if the browser is zoomed in or out (for browser interfaces or programs)? What if a user is using accessibility features like high-contrast text or a screen reader, or not using a mouse?
Or perhaps you'll be testing state trails - if you are on screen A of a program, and go to screen B, then back to screen A, can you see everything you would expect to see? Do you lose information which was on B? If so, do you get a warning? If you go from A to B to C and back to A, does that cause problems anywhere? What happens if you're halfway through a process or transaction and you shut the program down, or switch the computer off, and then try to go back to where you were? Are there any issues if you run two copies of the program at the same time on the same computer? What about if you run one on a computer and one on a phone, but logged in as the same user on both?
And so on and so forth. Essentially, it's a firehose of what-if, what-if, what-if, which is actually something aspie tend to be fairly familiar with, as it's not uncommon for us to want to be really, really sure about the parameters of a situation or the rules of a job or relationship before engaging. This is exactly the same thing, but now you get paid for asking endless variations of those questions.
One thing I have found is that it's possible to get a little too hyperfocused on very small things - testing and retesting and re-re-resting a single input field with increasingly bizarre tests, for example. If you have trouble getting caught in or not being able to break out of such things, set a timer or some such, write down the results you've mapped out to that point, and move on. Or, if a boss/developer says "OK, you've tested that enough", note that down in the testing logs and start testing something else - the previous thing is now officially Not Your Problem until you're asked to test it again.
Another aspect is getting hyperfocused on a type of test, such as input strings. If you ever find yourself not being able to think of anything else which could be tested about a program, go looking online for other testers and get their advice. Often there will be entire fields of tests which seem blindingly obvious once you hear about them, but which you didn't think of right away, or didn't think were in 'scope'. A program may appear to run perfectly well, for example, but how well would that translate to a new platform? Could disabled people use it easily? How about something less obvious, like being color-blind? Might there be simpler ways to enter data or perform actions? Could it be expanded to also provide other related functions? Would it market well to potential target demographics?
I'm not saying those are questions you may always have to consider. Being one person in a huge testing team for an international employer will probably see you having a far more rigidly defined scope for your work than, say, being the only tester for a small software shop, where you might be asked to chime in on nearly every aspect and wear many (metaphoric) hats.
But yes. All in all, the job mostly comes down to "try and break this new thing in every possible way so that it's not the final users who are the ones to discover any flaws".
You can also read up on the software development cycle, development methodologies such as Waterfall and Agile (which may influence your testing job's setup and some of its practices), and the ISTQB certification (and surrounding software testing terminology).
17 Feb 2020, 3:20 am
