Have you ever experienced that cloud of confusion paired with some mild “imposter syndrome” when someone mentions the words “IT” or “software development”? I promise you that you’re not the only one. For years I avoided anyone who wanted to talk to me about coding and anything related to it. Whenever someone just mentioned “Java” or “C++”, I would shut down and not engage at all. Sounds very drastic, I know, but this anxiety all stemmed from a lack of understanding of coding, software development processes, and the great unknown surrounding it.
Funny enough, years later, I found myself at a crossroads; go into IT or risk losing my job. I was the production lead for a company that had a big IT department. The production side was busy slowing down, so much so that I had to move to another department. One day the CEO called me to his office and asked me if I wanted to get involved in “testing”. I had no idea what it entailed, and all he said to me was the following: “Just break the system.” Those 4 words changed the course of my career and life. I was intrigued, so I decided to give it a go. As soon as I started in Quality Assurance, or QA as it’s also known, I realised how much I enjoyed it and how much I had missed out on because of my ignorance and lack of knowledge. Who knew the girl who never wanted to speak to a developer, would one day be on the path of becoming one herself.
And so I entered the IT world via the QA entryway. QA means that you’re the custodian of the quality of the product, system or platform of your company. At Polymorph, we believe the world needs better software, and as a QA, you get to ensure that that happens. As I mentioned before, your job is to try and break the system without necessarily having to fix it yourself. “Breaking the system” isn’t as bad as it sounds; you’re actually doing a good thing. It’s about being curious enough to find the issues before someone else finds it. You don’t want the end user to come across a defect that causes the app or web page to crash, preventing them from being able to use your platform. So you find those weak spots first and then report it to the developer who built the product so that they can fix it (we can chat more about the development life cycle in a future post). You also get to be part of a bigger team, working on achieving something great! You get to witness an idea grow from its infancy stage all the way to it being all grown up and ready to go into the big wide grownup world.
Sounds pretty simple, right? And it is, but for all this to happen, you need to start at the beginning, with manual testing, before automating the process. Manual testing includes writing test cases and executing them against an application or webpage. A test case is any scenario you would want to test. For example, your company has a website with a ”Contact Us” page. So an example of a test case in this scenario can be to test that a user can successfully send a message via the “Contact Us” page. You also get various different types of testing, for example, regression testing, smoke testing, exploratory testing, and many more. Regression testing is when you test a system’s main functionality to ensure that no regressions have occurred. Exploratory testing is by far my favourite. This is where you explore the system to find vulnerabilities and bugs. A bug is a term used to describe a defect or flaw in the system. It’s your mission to test the software and ensure it’s as bug-free as possible. It’s important to note that software won’t always be 100% bug-free, but as the keeper of quality, you want to ensure that the end users of your product get the best possible experience from using it. Exploratory testing is also where you get to discover “Rain Dance” bugs. A rain dance bug is the term given to a defect when the replication process of that defect isn’t as simple as it seems. Meaning, “I clicked the top arrow, then entered the world “hallo”, then removed the text and clicked save and BOOM, the system crashed. You’ll be surprised how consumers actually use products and systems, and they always have a way of breaking it in a very “unconventional” manner; hence the birth of rain dance bugs.
That’s another thing that makes being a tester so much fun; you get to test various different products and platforms relating to different industries and sectors. You can become an expert in testing financial technologies like payment systems or banking apps. Or you can become a tester for an NGO. The possibilities are endless.
Should you at some point feel like manual testing might not be your final or only destination, then automation is another great avenue to explore. And speaking from experience, once you start exploring, you’ll want to keep going.
Automation is where manual testing meets coding. Now before you close this article because I said the dreaded “c” word, just give this next part some attention. When doing automation, you basically write your test cases in a certain language, for example, Cucumber with Gherkin (I’ll explain more about that in a bit), and then you can automate these test cases. Automating test cases means you’re enabling the computer to run your tests for you. It’s basically job creation, in my opinion. The benefit of automation is that the computer can run regression tests in the background, freeing you up to focus on exploratory testing. There’s a whole host of short courses one can do to upskill yourself in the area of automation, so you’re not left to your own devices to try and figure it out.
If you dive a bit deeper into the world of automation, you’ll hear words like Cucumber and Gherkin. We’re not referring to the condiments they put on your big Mac. I’m personally not a fan of those, but the Cucumber and Gherkin used in automation I’ve grown to like. “Gherkin” is the language used to write automated acceptance tests, and “Cucumber” is used to execute those automated tests. We use a “Given”, “When”, “Then” format when writing a test case, which we call a feature file. And Cucumber reads this feature file and executes the test script for us. By following this format, I’m telling the computer exactly what output I expect from it. For example, “Given” I am on the Login page of our website, “When” I enter my username and password, “And” I click the login button, “Then” I am directed to the Home page. Here I instructed the computer to test a login scenario, meaning that when I log into the system as the user, I should log in successfully.
The great thing about writing feature files in this format is that anyone can look at the test and understand what scenario is being executed. For example, “Given” I am on the Login page of our website, “When” I enter my username and password, “And” I click the login button, “Then” I am directed to the Home page.
The entire feature file follows this structure, so it makes it easy for a QA to write these scenarios and then for a developer to bring it all to life. Cucumber.io is a great tool to use to create your own feature files. You can play around and get a feel for how the process works. If you go down even deeper into the rabbit hole of automation, you’ll find more avenues along the way, such as the ability and skill to add step definitions to your feature files. Step definition files store the piece of code needed to execute the scenario defined in the feature file. We can explore that avenue in a future post.
All in all, testing opens a world of possibilities in terms of work avenues to embark on. You can go into automation, become a full-time developer or even move into another area of the product life cycle altogether. Another thing that makes being a tester so much fun is that you get to test various different products and platforms relating to different industries and sectors. You can become an expert in testing financial technologies like payment systems or banking apps. Or you can become a tester for an NGO. The possibilities are endless, and the IIT world is your oyster.
“But how can I work in the IT industry if I don’t even have a computer science degree or diploma?” “How will people take me seriously if I don’t have the academic credentials to back me up?” I had the same questions. A great way to learn more about the basics of testing and to gain an understanding of what the field entails is to complete the ISTQB (International Software Testing Qualifications Board) exam. I know the word “exam” can be daunting but don’t let that put you off. This qualification helps you to become internationally certified, and it is an ideal way to get book knowledge about the QA field; knowledge that you might not get elsewhere. This is a great way to kick-start your QA career.
As a QA, there are also many opportunities to give back to your community. You can mentor other individuals who want to enter the IT industry through testing by sharing the knowledge and experience you have gained and guiding them along the way as they upskill themselves.
Basically, what I’m trying to say with this article is that don’t shut the door on something just because it’s unfamiliar to you and you don’t understand it. Read up about it, job shadow someone you know and trust, and try and get first-hand experience and information before making a decision. The IT industry is extremely exciting and ever-changing. There is always something new to learn. So if you think this industry might be for you or QA might be an area you would like to explore, go for it.
