An advice from a person passionate about testing:
-> Have you ever been in a situation where you’re out of college and hired by an organization for the role of a Quality Assurance Analyst or in general terms as a “software tester” instead of a developer?
-> Have you also been advised time and again by a bunch of people called “seniors” to opt for a project that will provide you Software Development experience instead of testing?
-> Have you been told that it’s okay to be a tester in the initial phase of your career, but later you must move to a development role or that your growth will be stunted if you stick to the testing role?
-> Or have you been told that there is very little skill involved with testing?
What You Will Learn:
If you find yourself nodding for any of the above questions, brace you! Because here’s an advice from a person passionate about testing and intending to remain in the same field for a very long time!
This article not only showcases why testing is equally or more important than development, but also that discovering defects or bugs requires vision, fore-thought, talent and a tremendous amount of skill.
I have also tried to express a few suggestions/ tricks to be able to dab on software’s weakness and expose defects.
See Also => More tips to find bugs in an application
What is testing?
If we go by a technical definition, then testing is a detailed investigation process whereby a determination is made whether a piece of code or a product which is intended for customer use is meeting the specifications it’s required to. Simply put, testing can be broadly defined as a practice to figure out if “something is not right” or “something can be even better”.
Needless to say, this process must be carried out with the motive of discovering errors or rather, with the aim of ensuring that the product or feature is meeting / exceeding the expectations.
When you closely think of it – isn’t testing deeply rooted within our daily lives? Let’s take a very common example of shopping. When you as a consumer go to an apparel store, you have a set of ideas in mind before purchasing an apparel. The first and foremost thing any consumer does is to try on the outfit and check if any alterations are required in size. Doesn’t this activity in some way comprise of testing or validation and isn’t it important?
Likewise, in software – Bugs or errors will inevitably exist in any feature or product. No matter how perfectly a feature or program is coded, there is always something amiss. This probably has nothing to do with the capabilities of the developers, but most often because the piece of software turns out to be rather complex and grows beyond the control of the developers to handle this complexity.
Have you also given a thought of how many implementation/ design defects can arise out of sheer complexity? Interestingly even 50% of development time is spent in testing to make sure the code is working as per design. Secondly, the cost of fixing a bug or an error is much lower in an early stage of the SDLC, than at the later stage.
Another key aspect to consider is that – In a market of constantly emerging technologies, with organizations developing several competitive products and pitting them against each other, what kind of product do you think a customer or consumer would prefer? Isn’t it safe to say that a customer will want a reliable, stable, easy to use a product? Here is where we as testers step in and play an invaluable role in the quality of the software or the product.
Thirdly, for any high-level product demos either to the stakeholders or the customers, the particular technical representatives firstly approach the test team for their help and rely heavily on their reviews to create customer demos. It’s easy to see the technical bandwidth involved in being a tester.
Also while testing, have you ever asked yourself this simple question – why are we doing something this way and not the other way? If so, then you are in a good place to even suggest enhancements, wish-lists and in some cases, kick start a Proof of Concept!
A defect can, therefore, be described as a program or feature failing to meet it’s expected results or an unsatisfactory condition that prevents the user goal from being achieved.
With the discussion above, as testers or as I would prefer to put it – as “test developers” the primary goal for a tester is to expose as many defects as possible as early as possible. This requires not only a keen eye but a bent of mind that can drive down to the core of the system and determine which cases can cause a failure.
While developers have their knowledge limited to only the feature or program they develop, as test developers we are those fortunate few who have the opportunity to gain complete end to end knowledge of the software/product and in some cases, we have the platform to even drill down to the architecture level to expose potential problems.
So who do you think has more skill and knowledge? :)
While each individual has their own distinctive style for testing, here below, I am attempting to pass on some suggestions and tricks to ensure good test coverage and maximum cum valid defects finding through my experience.
This mainly entails gaining in-depth knowledge on the feature being implemented.
Needless to mention, the research and knowledge part of it is inevitable in any phase of testing and bug finding. After the preliminary stage of self-education, a good amount of thought must be invested in planning the test scenarios.
At most times in the testing cycle, the test team has some amount of time on hands before the actual testing commences.
Getting to the most interesting part of our job– Testing and in turn finding defects! We are those fortunate people who make developers improvise their code quality to a large extent.
There are 2 main reasons for this:
a) Most developers would not want to have defects against their name due to tight schedules and may reject the defect asking for more information, just to buy some time. In certain other cases, they may genuinely not understand the steps to recreate a scenario that the tester has followed and may return the defect for replication, again burdening the tester.
b) The second reason is that most often we work with teams that are globally distributed and the fix may need to come from another developer sitting in another part of the world. So if the problem is clear to a local developer that you initially filed the defect against, he will make it a point to add his findings to the defect and re-direct to the person who has to fix it. This avoids time delays in generating a fix for the defect as the developers in a different time zone will already have some minimal information he needs to work on a fix, again preventing several exchanges between the tester and developer and reducing the age of the defect.
Again – communicate with the developers to understand what is going on. In my experience, I have always seen that the developers encouraging testers to understand the code flow and the logging. Once you’re well acquainted with the logs, you can immediately detect where a test fails by its stack trace. Sometimes you can also easily detect where to catch more defects!
Here is another example why getting familiar with the logs is important. During our testing cycle many times we have observed that a particular test flow wise, the feature or software behave as per the specifications. However, a field issue was caught at the customer end that during the entire scenario flow, the customer observed a series of null pointer exceptions in the logs! This came back as a critical test escape because this is certainly unacceptable! People had to be immediately deployed to develop scripts or tools that would give a direct report of the Null Pointer Exceptions.
The above pointers can greatly influence testers new to the industry to develop the mindset that is needed for ensuring that the quality of the product is measurably high in standard.
Personally, the above practices have helped me immensely in being one of the most sorted out testers in the unit I am part of. Also remember, the majority of Subject Matter Experts in any organization are mainly testers.
So enjoy and happy bug finding!
About the Author: This is a guest post by Sneha Nadig. She is having 7+ years of software testing experience and currently working as a test lead in a top MNC.
Do let us know in comments below if you find these tips useful. Expecting more tips/suggestions from our expert readers.