What is Testing?
The ultimate question, what is testing? In case you aren't aware yet, there is no one answer. There are many different versions of testing (Hopefully I will post about some of the different methods at a later time). But the biggest point I would like to make in this post is about testing in the context of "follow the steps" testing vs thinking testing. The difference between the two of these, and which you end up doing, can make or break how you feel about testing.
"Follow The Steps" Testing
Follow the steps testing is, sadly, how most people still view testing. This is a testing team that simply follows the same steps for every new feature or bug to make sure that nothing in that single flow is broken. This means that every time something in the code changes the same steps are performed to make sure that there are no new issues.
Before I continue I feel the need to remind all readers that this is an opinion blog and this blog shows only my own personal opinions.
You will inevitably hear someone say that this type of testing is not helpful. That anyone (even a highly trained monkey) could follow those steps and report back whether or not that test was a pass or a fail. This is the kind of mentality that simply helps to promote the "testers are less than developers" stereotype that you will encounter in the tech field. This is a stereotype that I will tackle time and time again in future blog posts.
The second largest thing you hear is that this type of testing can be automated. That is what I hear over, and over, and over again. And they are not wrong. This is a perfect candidate for an automated test suite. Make a script that can follow those steps that you are currently doing manually and free yourself up to do other types of testing.
"Follow the steps" testing is the waterfall model. Ask any person who as worked in the tech field in the last 5 years (not in a large company where time slows down, trust me I've been there) and we can all agree that is outdated. So is this type of testing.
First of all, yes that name is horrible. No, I do not have a better way to explain it but I am always open to suggestions! Thinking testing is just how it sounds, it's the type of testing that forces the tester to think for themselves. They have to be the ones who are bringing new ideas to every ticket or new code change that they encounter.
Thinking testing is what is allowed to happen once you have started the process of automating the "follow the steps" testing. I'm not saying that you need to have everything in that area automated, I can promise for as long as you are adding new features to a product there is more you can automate. Additionally, the more new technology that comes to light the more likely it becomes you can automate some area of testing you haven't thought of before. Again, this will all be discussed in future posts I'm sure.
Once you break out of the script (ironic word choice since most of the time writing a script is what allows this) that you are following for testing you have to start to think for yourself. This is the area where you learn that testing is not for everyone. You absolutely need to have a passion for the work that you are doing in order to care enough to try different things. This area of testing is where you make the choices, you make your own test plans, and you try something new every single day.
The biggest perk to thinking testing is that every single day is different. As long as you continue to think about your testing and make sure you don't fall back into "follow the steps" testing then this will lead to you learning about your product as well as learning about yourself through the things that you will try.
New Technique Challenge
A lesson my first mentor did with me was done while she was away for a week. She challenged me to try something new every single day that she was away and document what I did, what happened, and what I learned. Every day I had to really think about what I was testing and try to find out what I could do differently than I normally did. I'm lucky that I did this early in my testing career and now I try and challenge myself to this every single day. Find something that is different about this ticket or just think of something I have never tried before and just do it.
What I learned was that I had accidentally gotten myself into the habit of assuming I knew what had changed with this ticket and forced myself to break out of that. This lesson has stayed with me and I always watch when I get a new ticket and write down what my assumptions are ahead of time so that I can make sure I don't only think in terms of those prior assumptions!
Now I challenge every single one of you who reads this to do the same! Document what you try, what happens and what you learned. Feel free to keep your findings to yourself or post them here for others to learn from you.