Perceptions about software testing

Hello. For persons who are new and still fairly new to software testing, what was your initial perception of this career before starting?

How has that perception changed as you got more into the field?

1 Like

Honestly, my initial impressions were not good, which is not a big surprise if you are in a place where testing is not appreciated at all and blamed for everything. I didn’t think it was a serious role for a while and I spent some time learning to become a developer.

Over time I changed my mind, I moved to a bigger company where “QA” was done in a very serious way and software testers were highly technical people, writing automation code, using databases, testing APIs, etc. Another thing that helped a lot is getting more involved in the testing community, I learned about exciting new approaches and testing philosophies.

Another thing I like about testing is the fact that it’s such a broad field with tons of different routes you can take. Even if you end up not liking being a tester the roles expose you to so many aspects of the software industry that it can make you better prepared for many other roles.


Great question.

I chose testing over a long career in IT support. Previously supporting an old bespoke system, I was involved with the entire delivery life-cycle, including the testing.

Testing was always looked at as a ‘phase’ that could be sacrificed if needed - and it was always biting us in the bum. I knew the business was (… and probably still is) doing it wrong, but I couldn’t change how the business operated unfortunately.

So when I moved into testing properly as a career, it was really refreshing to see new approaches and open minded thinking when it came to ensuring the quality of products. My pre-conceptions of the industry were off, as I completely underestimated how ‘up-and-coming’ testing, or now rather ‘ensuring quality’ actually is now.

Testing is a super far-reaching industry in software development, which just gives you this endless stream of learning opportunities.

To be honest I didn’t have an initial impression as I wasn’t working in tech when I heard about it as a role. My initial interaction with testing came from reading ‘The Art of Software Testing’ by Glenford J Myers and it gave me a great impression of what an interesting role it was. Once I started in my first role I haven’t really looked back, even in the bad places it was people and not testing that was the problem.
Great questions though, I hope you get lots of interesting answers.


This is an amazing question, @carltonjcarib. Thank you for asking it here.

Before starting my career in testing I was working in a customer service team in a now-defunct Building Society (read, bank).

We were told there was a new fancy piece of software coming soon (Fiserv on IBM DB2 AS400 for those who want a trip down memory lane) and “Would anyone like to do user acceptance testing (UAT) before we roll it out across the entire company?”

I knew I wanted to get some sort of job in IT and it sounded interesting. Prior to that, I was always annoying my team lead and senior management with questions about why we couldn’t do this and why we couldn’t do that. :sweat_smile: I had zero perception about what testing was at the time. Zilch. I guess I thought it was something to “help make sure it works well for my team”.

So I did three weeks of UAT and I absolutely loved it! I was offered a permanent job to move into the software testing team. :smile:

At that time it was all about test scripts which I had no perception of beforehand other than some basic scripts I’d been given to run through during UAT. So I thought testing was about a) following testing steps b) raising bugs.

As I got deeper into testing and moved jobs I realised it was way more than that and became very interested in exploring with the goal of discovering useful things that threaten the value of the thing being tested. I opened my eyes and ears to the possibilities of structured and disciplined exploratory testing.


For me it was the complete opposite of @mirza
I never expected the amount of backlash you can get for raising a bug, how testers are not valued, need to be careful how we talk about our findings, … It does depend on the company/team, but I’ve heard similar issues from other testers in the community.
I also wasn’t really aware of non-functional testing before I became a tester. It’s now a big part of my job.

Initially, I used to work as a PMO developer for one of the testing accounts with my first organization. When I used to see the testing team there, I was not very positive about the work that software testing might be having.

One reason for that was that I used to mostly see them creating tests in Excel and that was the only first impression that I had on them. I used to think that the work of a tester is not creative. It’s kind of repetitive - filing documents and maybe running those.

But later on, when I came into the software testing profession, I realized that it is a lot more fun, it is a lot more creative you can do a lot with software testing . Today, I think it resonates with who I am as a person and I really love this.

1 Like

My initial perception for software testing is the job that hammered around and see what wrong in software + It’s a escape pod for people who graduated from IT,CS related fields but don’t want to do coding stuff.

Turn out, The first perception was change when I got chance that work with team that care about quality as well and I kinda make understand a bit of advocate quality, collaborate more across the role and erase the picture that QA as a gatekeeper.

The second perception still not change that much.

1 Like

Well I started testing video games by looking for glitches when I was ‘young’ so when I got to software testing when I was looking for a job, I kind of had the same perception. Finding bugs in the UI and on the backend.

But it was so much more then that. I still have a difficult time trying to explain it all towards non-technical people what a tester does.

It used to be ‘find bugs’ but now that finding bugs has changed towards ‘finding performance issues, security flaws, business logic flaws, trying to nuke down servers & services’

I’ve been doing testing for over 10 years professionally now and I’m still excited and surprised by new things that I discover.

I’m a huge fan of edge cases and going out of the box to break applications.
It went from “humping walls to fall off the map” to “doing crazy workflows with hundreds of requests with crazy payloads” to get the weirdest result.


My initial impression of software testing was that a) it involved a lot of documentation writing (test cases, long strategy documents etc.) and b) that it was something I felt I would be good at but had no idea how to break into.

When I left Cardiff to move up North (for love, you understand), I was mostly applying for Marketing and Arts Administration roles (as that was my background up till then), but by chance I spotted a Tester job advert for a digital agency and applied for it on a whim! It was the agency’s first ever tester, and I only had a month or so of experience during my notice period at my previous employer (as my marketing/comms replacement had been hired!), so neither of us had any preconceived knowledge about what was expected.

I did well enough at interview - they gave me a webpage with deliberate bugs; I completed the task and also found some bugs they didn’t know about - and they decided to hire me, so it was a great opportunity to learn the ropes whilst developing a custom testing process that ‘felt right’ for the fast-paced and under-resourced nature of a digital agency workflow!


I started my current junior tester role a year ago. I didn’t have any other perceptions about software testing than unit testing (since I was self-studying to become a front-end developer). I have always been very critical to my own codes (or just simply I’m a perfectionist) so the idea of testing an application to find bugs is really intrigued to me.

In my first few months working as a tester in a development team I thought testing is about checking that the application meet all requirements which were explicitly defined in the beginning of the development cycle. Now I have realized that requirement checking is not real testing. So I have set out a mission to change my approach to testing into more exploratory and risk-based. I’m glad to join this huge community of software testing professionals where I can learn to build testing my professional career.