A Humble Note to the Audience
I am a beginner and an avid learner. In this article, I will share my journey of becoming a Software Quality Analyst by translating my previous experience in Journalism and how I am presently combining my Journalism and SQA expertise to access the world of Cybersecurity.
There are many seemingly ‘unrelated’ skill sets I have ‘hacked’ to tailor to my SQA job responsibilities alongside basic application security testing. So, the terms Testing and SQA will often overlap with my ongoing Cybersecurity learning journey. First, I would like to brief the transitions of my job responsibilities before getting into further details.
The Transitional Periods: Journalism to Software Testing
I started my career at the Daily Observer print version as a city desk sub-editor after completing my graduation in English Literature and Linguistics in 2014. The newspaper was a hub of veteran senior journalists from the ‘typewriter age,’ and the year itself was a transitional period to digital journalism. The journalists were interestingly either indifferent or facing a bit of hardship in adopting new technologies like editing copies in text editors, utilising news agencies and emails from correspondents on the internet as news sources.
Being the junior most staff in the house who had some handy technical knowledge, I was unofficially appointed to another post as a communicator between these journalists and seemingly 'new technologies. So, apart from my regular journalism, I became an unofficial tech support for them. I spent countless nights listening to their technical hardships, analysing their problems, and finding out solutions for them.
I took full advantage of this opportunity by working closely with technology bit reporters, reading technical books, blogs, and articles on programming, problem-solving, computer systems, operating systems, cybersecurity… anything related to computer systems and the internet.
In 2018, I joined the New Age print version as a sub-editor. A few months later, I was shifted to its online version.
I had an opportunity to interact directly with journalists from the spot, collecting information from them, cross-checking facts, preparing to-the-point stories, and publishing them on the portal in time. The fun parts in this section were analysing reader behaviour from google analytics. After primary analysis, we used to fix what type of stories will be published at which time. I also had to work closely with our technical team if there were any unusual behaviour like 502 errors, any story or photo missing, news item format issues, etc., in the web application. Gradually I got an additional role of ‘Website Quality Analyst’ here.
During this period, I wrote Myths and reality of a parallel world’s defence mechanism after a month’s effort. This piece was published in the now defunct youth segment of the newspaper, ‘New Age Youth’ — one of the sweetest memories of my career as a journalist.
Later in 2021, I finally joined Penta Global Limited as an SQA — my real-life entry into the Information Technology industry.
Cordial thanks to my childhood friend Farhad Naeem who first taught me programming and recommended me as an SQA before my CTO.
So far, this is my story. Remember that I am not an expert Journalist, SQA or Cybersecurity professional. The below writing is my personal opinion on the most important skill sets and how I translate them into my daily job responsibilities.
Communication, Communication and Communication
The way humans communicate makes them stand out from other animals. So, it does not matter if a person is an introvert or a ‘geektrovert,’ s/he needs to maintain some level of communication; however, the audience will vary in size.
To be precise, an ‘introvert’ most of the time communicates with the self, while the ‘geektrovert’ communicates with one or two specific cliques. A good problem solver knows different ways to communicate with problems, and their solution, utilising required tools and translating the solution for specific purposes.
So, as a side note, I would advocate for a ‘weak’ student as a person who is having a sort of hardship with communicating the core concepts of a specific subject e.g. Math or a Foreign Language, as well as the classroom and instructor. It is NOT that the individual lacks ‘intellectual abilities’ like toppers.
As an SQA, tester, or cybersecurity professional, a person must have good communication skills to access the process of
- Business,
- Development and
- Technologies
The very basic triad can be explained like this — A firm employs developers if a concept has business values. Developers then use different technology stacks to realise the concept into a software application and deliver it for testing.
So, an SQA must have some solid communication skills to understand these scenarios for a better test plan and execution to ensure product quality and security.
I had to frequently put on the shoes of readers, reporters, and sub-editors to publish timely stories in my past career. I had to train my brain for any inconsistency in information in the shortest possible time. Let me share a recent experience as an SQA. We have deployed a stable one-stop service for the national export/import authorities for around three months. This system consists of different forms to be filled out by investors to obtain different certificates from the authorities concerned. One of the forms had the following feature (I’m using dummy labels)
On a good sunny Sunday morning, my project lead, who was then busy with another project of our firm, sent me a short message to immediately deal with a client requirement that the Sum field would be editable. At first look, it seems insane, naturally. But my journalist instinct gave me a hint that there might be some communication or information gap.
So, I quickly contacted the client-side IT Systems Expert. After analysing the requirement, the fact was clear finally. They wanted the third field to be an individual editable numeric input field, and there would be no summed-up value of Num Input 1 and Num Input 2 in this field. To sum up, the calculation was NO longer needed.
Good communication skill lets a tester make authorities concerned to understand the weight of a bug and the values it adds to a product. To be precise, if an SQA or Tester is good at communicating with Problems, Machines, and Humans, it will build a concrete base of any skill set. Among them, a few are
- Understanding and getting involved in Software Development Life-cycle
- Simultaneously interacting with development, management, and client teams
- Mastering problem-solving skills, required programming languages, and tech stacks
- Getting a clear picture of a system under test and discovering bugs
- Understanding the weight of a bug, clarify development and management teams the value it can add to the product
- The list goes on ….
Not all Reports are Published: Some Bugs are NOT Bugs
Those who have some in-house experience in media or submitted contributions to one are aware that all the stories are not published because it is a waste of time and sometimes damages the reputation of a house.
A seemingly quiet newsroom is a place where the storm takes place in the brain of journalists, like the development room in the Tech Industry. They are busy with problems worth solving.
For example, a development team is busy implementing a new feature on a tight timeline. There are one or two typos in the feature. As well as, they did not tokenize some sensitive API calls due to test purposes.
Should a tester make reports on the aforementioned issues? No, it is a waste of time and effort. The tester should rather be aligned with the development team and keep track of those issues. S/he should ensure that the issues are implemented before the version goes to production.
Personally, I define a bug as a BUG if it
- Breaks system or features
- Uncovers security issues and
- Generates bad reputation of a team or firm
Yes, when there are no bugs, a typo can question the language efficiency of a team.
A simple text box alignment issue can also generate a bad reputation of an Omega SQA as a cherry on the top, especially when s/he is under a close-door ‘interrogation’.
Adopt OWASP
It all works. The reported bugs have been fixed. Now we are prepared to seal it off ‘QA Passed’.
Hold on!! During the dawn of Web3, almost every software project interacts with the Internet and API calls to different extents. This makes software applications vulnerable to various types of threats in the ‘Wild Wild Web.’
So, adopting OWASP is not only a good choice for further ensuring better software quality, but I have found a solid platform to start my journey towards cybersecurity practically. The project OWASP contains many Top 10 vulnerability lists on Web, Mobile, API, and IoT software applications that are good starting points for beginners and references for experts. I assume the steadily growing project will soon cover the Top 10 vulnerabilities of AI, ML, Blockchain, and W3 applications. I would share a bit of my experience here. Our production deployment was delayed for about a few weeks, and I had a golden opportunity to conduct penetration testing on our web application. I found three textbook vulnerabilities from OWASP. The finding, exploiting, PoC, and reporting phases were equally enjoyable to me, where I had another golden opportunity to utilise my technical and journalistic skill sets successfully. Among them, two critical ones were fixed, and the rest had been put in the backlog. Why?!! Keep reading …
Discovering Vulnerability: It is the Beginning of a Long Journey
If we find and can reproduce a vulnerability, e.g. an injection point somewhere in an application, it is not the ending and often not worth a formal bug report. It is often the tip of an iceberg. Because a vulnerability is worthless sans a proper exploit. In my words, an exploit is a procedure to take advantage of a vulnerability to modify a software application in such a way that it was not meant to be. So, in this case, the better approach is to inform the development team and keep track of if a new feature or any modification in the system can open a risk of exploiting the vulnerability.
For an oversimplified journalistic example, a news reporter submits a 500-word story about bumper production of main staples in areas where it has been growing constantly for the past 40 years, contributing to a country's economy. This ‘news’ is worth mentioning once in a news story as a piece of information. This piece of information might hit the headlines if the country faces a food crisis despite the bumper production of that staple. So is discovering a vulnerability. It takes effort and time to find out one. But without a proper exploit and a proper workflow to utilise it, the discovery is often not worth a detailed report. So, we must develop a way to exploit a vulnerability when we find one. Sometimes we have to wait patiently, like a real-life cyber criminal to develop a workflow to use the vulnerability to produce PoC that brings the true weight and relevance to our report.
Tooling: The Samurai Dilemma
“They are my slaves [ books and papers ] and they must serve me as I please.” - Karl Marx
Tooling does not give birth to an artist, artiste, tester, or person who stands out in her/his arena. I cannot remember any argument on Albert Einstein’s efficiency in using calculators, handwriting, or accounting. Have you ever heard or read art critics arguing over which tools Leonardo Da Vinci or Michelangelo were efficient on?
Do we expect a person efficient in the grammar of a certain language would contribute to the literature of that particular language?
The answers are big, Big NOs. The person behind tools defines the shape of a piece of art.
As any testing is an art, this is true for Quality Assurance and Cybersecurity.
Hold on! There is a catch. In reality, some tools are so embedded in certain crafts. For example, is a nylon string guitar for classical music and a Nmap for network scanning.
OK, here comes my ‘Samurai Dilemma Theory’
Anyone will want to be a Samurai after seeing their depiction in anime and movies. But it takes a long time, rigorous training, and extreme devotion to become a samurai soldier in reality. So, if a random person is given a samurai sword to show some acts, chances are high that he would injure himself. Moreover, he might lose his life on the real battlefield. On the other hand, the result will be the same if an expert Samurai guru wants to fight against modern artillery without ‘modifying’ her/his sword. So, the point is a Tester, or SQA, will choose, modify, and develop her toolbox utilising creativity and responding to needs. S/he would not stick to a specific testing method, OS distro, or tool set but rather modify existing ones or adopt new ones. In the end, for creative minds, Windows vs Linux, Python vs Ruby, C++ vs Rust, and VIM vs VS Code arguments don’t matter. They just pick or discard their tools to create a piece of art. Do you need some Proof of Concept about the classical guitar example I mentioned above? Just listen to Tim Henson and see how to play rock pieces with a custom nylon string classical guitar !!
In future writeups, I will show you how Nmap can be used in a bash script on a raspberry pi box to build a basic 24/7 intrusion detection system.
A Note on Automation
This is the bonus section before I wrap the long story up.
I was an automation freak when I started my career as an SQA in August 2021. A few months later, our tech lead and development lead held a meeting with me. They assured me that they will inform me when we REALLY need test automation suits. Until then, we should focus on ‘manual testing.’
I researched the internet and realised there is no such thing as ‘automated testing.’ It is yet another utility tool under the belt of a seasoned tester to ensure a software application's quality or security measures. Although, this point of view has criticism.
I have never heard of ‘automation’ hypes in the world of cybersecurity or penetration testing other than vulnerability scanners like Nessus or frameworks like Social Engineering Toolkit (SET) or Metasploit. The only field where the term ‘automation’ has become a buzzword in the SQA world. Why? This answer needs in-depth research and an entire article on the topic. Dear learned readers, please pardon my ignorance if I am wrong.
There are many AI tools in the wild for writing articles and making beautiful paintings. But, human intervention is a must for fine-tuned results as of writing this article on November 29, 2022.
Yes, there are arguments that GitHub Copilot and AI will rule the world in the near future, which I am not taking into consideration in this article. Rather, I would reiterate that automation is merely a tool in the toolbox of a tester, as discussed in the above section.
A seasoned SQA or Security Professional will miss certain important findings if they heavily depend on automation results, while beginners like me will OBVIOUSLY miss a lot of interesting things that will build a solid foundation of their understanding of the art of testing.
Personally, I prefer automating a few regressive features with well-handled corner cases in a stable system. This will add good value to testing by saving some regression test time and effort given by testers.
If the requirements of a product change too frequently in a cyclic order, test automation will NOT bring any value against the given time and effort.
So, confirming a product’s stability and pin-pointing test scopes are inevitable parameters to be ensured before we build our automation test suites.
Final Thoughts
Dear reader, you deserve cordial thanks for reading this long article. Here are some final words for my fellow journalists, SQAs, Testers, and Cybersecurity professionals.
The Reporter vs Desk and SQA vs Dev fighting is a long-existing tradition worth mentioning.
When we report a bug, a developer first tries to identify whether it is a feature we misunderstood.
When developers successfully deliver a new feature, an SQA suspects there must be one or more bugs, while security professionals are one step ahead to hack into their implementation logic. The internet is full of humorous memes in this regard.
This is a healthy creative practice because our ‘confrontations’ keep the information intact or deliver quality software applications to serve humanity in the end.
So, there is nothing personal if the concerned authorities ask us why a bug that is actually stashed under a 20-day-old backlog was not reported. And this will often happen if you are an Omega Tester and testing multiple projects. Just put on their shoes. They have critical problems, like us, to solve. The Omega Tester piece by James Marcus Bach is a must-read for every Tester, SQA and Cybersecurity professional.
Please feel free to share your opinion, constructive criticism, and professional advice with me.
Note: All the images are captured by the author.