Are there any passionate script testers? Martin Jansson
When looking for personel in general it is common that we want passionate people who love their work. Most passionate testers that I read about are usually part of the context-driven movement. Can there be testers out there that are really passionate about how they work in the heavy scripted test environment, where someone else does the thinking, writes the script and then hands it over for execution? What personal goals do you have when doing these tasks? Is your main focus in moving out of that zone so you also can do the thinking, write the test script and pass it on?
In the ET heavy environment I tend to see fewer roles and career paths, is this true? There are test leads, test managers and testers. Everyone want to test since that is their passion, no? You have fewer administrators and more doers.
In the scripted test environment I see more different roles and career paths. There are experts in certain domains, writing test cases. There are many test leads who spend their time trying to lead what is to be tested and exactly how. There are test managers allocating the very few testers in executing these tests. There are more administrators and less doers. A few times I’ve seen almost 90% administrators and 10% testers. With administrator I mean someone who has little focus on actually doing any tests themselves, and in some cases do not want to. One common management idea is that anyone can assist with executing a test script. This means that anyone can be a testers, thus you are not special in being a tester and you are easily replaced. There is no skill in being a tester since you just follow that script, no?
Are you then passionate about being a script tester?
Interesting reflections! However, I have some questions for you… 🙂 What is being passionate about scripted testing? Someone who really wants to work according to “do this, expect that, do that, expect this and so on” every single day, or is it someone who is passionate about testing but a believer of scripted tests? Also, regarding the career paths, I read it as you see one more role for scripted testing, and that is “test designer”. In that case, not much difference there. However, I believe in both ET and ST there is always room for specialists as a career path.
I see heavy scripted testing as where someone else does the test design and writes the test script for the tester to execute. In this situation the test designer pours his intelligence into the script, so that the tester just can execute it?
My concern is not using scripted testing. If we use them as a guide to specific area, as a reminder on how it could work etc. If we are not forced or being judged by following the script. If we are not defining what to expect at each turn. I do not see it as a career move in being knowledgable about a certain area in the test organisation. I promote generalists before specialists, especially if you are looking at a large complex system. I also promote that you learn and explore areas that you do not know so much about, that is what I tell testers in my test team.
I see the core function of a test organisation to perform testing, in many contexts. My concern in test careers is that they steer away from actually doing testing. I agree that specialists and domain experts are good to have as long as they are testing and utilizing their knowledge and spreading it to and with other testers. Collaboration and cooperation during test sessions.
I agree alot with “My concern is not using scripted testing. If we use them as a guide to specific area, as a reminder on how it could work etc”. Regarding career move, many (at least larger) companies have implemented steps of: expert, specialist, senior expert/specialst etc. I think this can enable someone to “stay in the lab”, continue to excel in testing (as a generalist) and still be formally recognized (mo’ money). Does this fit your defenition of career move/path?
You write as if the creation of administrative roles is caused by scripting. Isn’t it likely the root cause is the sheer amount of work? If you’re testing a one-off web app or GUI that you’re buying from a third-party vendor that will likely not be upgraded frequently I would seriously doubt a smart company would invest the time and money in buying the automation software, investing in a full team which would require a manager and then spending weeks developing automated scripts.
On the other hand if your company is investing hundreds of thousands of dollars building an enterprise wide billing/accounting, etc… system which would be receiving quarterly upgrades with plans on using this software over the course of several years, you would likely need a larger team. You would want to automate and document your test cases (scripts) so that if you have turnover, a lesser skilled person could assist with execution.
Everytime someone mentions scripted testing vs ET, they associate scripted testing with execution only. Any tester that executes a test case (whether it be automated, manual, scripted or otherwise) and doesn’t investigate the impact is a bad tester.
To answer your question, “Am I a passionate scripted tester?”…well, I’ll say I’m passionate, period. If I’m automating scripts to facilitate EXECUTION and that saves my company hundreds of people hours over the course of time, then yes, I’m passionate about saving money. If I can spend 2 hours writing a script to save me 20 hours so I can spend those 20 hours investigating logs, pulling statistics and identifying gaps between the system and the test requirements, I’d say that’s a good investment.
To critizize my own article…
I disagree with that “in general it is common that we want passionate people”. We want different kinds of people, with varied backgrounds etc. If everyone were passionate about something we might miss out on a special trait or persona.
“Most passionate testers that I read about”, well perhaps I need to read more and lift my eyes from the context-driven world.
“Can there be testers out there that are really passionate”, offcourse there can. You find passionate people who love their job everywhere.
“where someone else does the thinking, writes the script and then hands it over for execution”, I am sure there might be cases of this but most often all parties involved think and act.
“What personal goals do you have when doing these tasks” and “Is your main focus in moving out of that zone so you also can do the thinking, write the test script and pass it on”, who knows? People are complex, companies are complex, life is complex… everything is complex. By categorizing and making the world easier to understand does not make it less complex.
When we are talking about ET approach and ST approach we simplify and categorize things to understand better. I do not think we can make so easy judgements on what we think we know. If I had brought up statistics for a large set of companies and would have compared them it might have said something, still it might have not.
@Saam, “What is passionate tester?” I have no idea. I am passionate about a lot things, which can be extremely bad in some situations. When I see something new and interesting… I might drop what I’m doing and focus on that. Thus become less loyal to my current assignment. Do we want everyone to be like that? I hope not. I also think career paths is something that is not dependent on what approach you are following at the moment. In many cases you cannot create an organisation however you want to because you are forced to have some kind of basics, such as one manager per X number of people, another manager per X number of managers, ability to provide a career for those who are interested in titles and those who are not, and so on. So I think I over simplify by making the above assumptions.
@Chad, interesting that you bring in automation in this. When you automate something you do part explore and part test (or check). The test that you actually write are most often a check, not a sapient test (as Michael and James calls it). Still, the act in creating the test is very sapient and exploratory. With Model Based Testing you might be able to create random tests that are in fact not checks? Well, who knows?
So… thanks Saam and Chad for seeing through this. =)
Thanks for taking time to read my comments and for accepting them with an open mind. I would like for you to elaborate or perhaps give an example of something. When you say “The test that you actually write are most often a check, not a sapient test”, what exactly does that mean? An example would be great! Thanks!
Chad, if you have not already do check out Michael Bolton’s discussion about testing vs. checking. I recommend it highly. As I see it, it makes a clearer distinction between certain tests. An automated test is most often a check or several checks, as in you do something then verify a defined set of things. While with a manual test (or sapient test) you do something, then let all your senses pick up what happens and determine what is right or wrong, as you see it at that moment.
Links:
http://www.developsense.com/2009/08/testing-vs-checking.html
http://www.developsense.com/blog/archive/2009_11_09_archive.html
http://www.developsense.com/blog/archive/2009_11_10_archive.html
I have read his notes (and several other posts/blogs) regarding testing vs. checking and I couldn’t agree more that testers need to understand the distinction. My only issue with the way I’ve seen them discussed is that automation and scripted testing tend to get lumped into ‘checking’ and manual/ET tends to get lumped into ‘testing’.
I would like to see that discussion taken a little deeper. There is a difference between ‘execution’ and ‘verification/validation’. If you run an automated script with pre-defined validation/results, I would say you are checking. I would also say the same for someone exeucting an ET style approach with a result in mind. However, you can still execute scripts using automation and verify your ‘checks’, but take that a step further and observe what is happening during that execution. You can examine your logs and other system behavior and in my opinion, that would constitute a ‘test’.
Not sure if I’m really making my point 🙂 Anyway, keep fighting the good fight!
@Chad, I believe I get your point. Please correct me if I am wrong. What you are saying is that you combine your manual testing with your automated testing (checking). Your manual testing can become more efficient since it becomes computer-assisted and your automated checking can become more effective as you expand the binary pass/fail criteria with a human investigation. Sounds great!
There is often a confusion about that it is the approach of ET and ST we talk about, not the actual techniques.
The essence of an automated test is most often in a sequence where you at the end want to verify something specific. It is this that, if I understand correctly, is the check. I’ve seen automated tests that were built on undo/redo commands using the history of the previous user and his/her exploration. The test randomly went backward or forward until you stopped it. It was not a scripted test, but more of an automated test you played afterwards. I would not see this automated test as a check.
There are many ways of creating automated tests and it would be wrong to lump them all into one category. If you create an automated test for a bug, I would say it is a check for that specific bug to not reappear.
Would it be a check or a test if you run data-driven tests with random data and other random input where your verification in the end of the test is that the program is “sane” to some extent? I guess it is hard to define.
But it is easier to talk about testing and these so called checks in automation when we do planning and especially when we talk about test automation to fully replace manual testing (which is not possible as I see it, or worth it).
Regarding “You can examine your logs and other system behavior and in my opinion, that would constitute a ‘test’.”, do the automated test look for something in the logs in its verification of a test that passed or do you use the “tool” to check for something in the logs? How do you work with automated tests? Do they run each night and you get a result or are they part of your manual test as a complement?
Consider all your written automated tests, can you categorize them into different types of test?