After spending more than a decade in IT industry and watching the evolution of Software Development, it's fair to say kin Software Testing has come a long way.
The responsibilities, expectations and accountability of Testing/QA team have changed a lot. How, Why, What, I will be explaining it further.
In comparison to 2010, things have changed a lot. For instance - Waterfall to Agile, Monolithic to Microservices, Functional Testing to Test Automation, Manual Deployments to DevOps. As a result, QA processes/activities have also matured in order to cater, comply and adopt these advancement.
Learning Software Testing (The Modern Way)
Test To Break Approach
One of the building blocks is to have a mindset to look out for defects. Verifying the functionality or acceptance criteria in user story is one aspect but trying different test cases, will definitely help to find the problems. It can be inputting invalid values, throttling internet while using application or testing application with different font size, resolution and themes. Some defects are identifiable only if we think from different perspective of customer, product, marketing.
Most of the times, things will be working as written in requirements. However, the difference will be created when we will think out-of-the-box and create scenarios freely using our imagination and experience.
Testing is the process of comparing the invisible to the ambiguous, so as to avoid the unthinkable happening to the anonymous. ~ James Marcus Bach
Understanding Business Domain
Testing a product without domain knowledge is like selling your product without knowing the ingredients of it. Domain knowledge plays a critical role when you are assessing a quality of product. For example, in healthcare domain, if we are aware about type of health plans/policies, it will assist in understanding why this product is built?
Similarly, it can be for payment app where different types of payment modes may have specific set of rules attached to them. Analysing each payment mode will open whole world of requirements which is what we want to uncover.
In fast-paced agile, most of the times, requirements/user stories are brief. Hence, domain knowledge provides an edge to identify missing/open ended cases or scenarios at the early stage of SDLC.
Attention To Details
Sometimes a spelling mistake, incorrect date of birth format display, wrong icon placement, wrong decimal position, can create chaos. This characteristic of attention is not built-in but require continuous practice. To begin with, you can start comparing UI design with actual product, read through the help text written in website/app to identify erroneous content.
It's attention to detail that makes the difference between average and stunning. ~ Francis Atterbury
Communication Skills
Communication is the real thing when it comes to group cohesiveness. We are working in a team which composes of Product Managers, Developers, Marketing, Stakeholders, Clients. Each member has different perspective specific to feature. Thus, listening to everyone, giving your inputs and then passing it on to others be in form of email communication or comments drives how a quality feature is gonna be built, tested and delivered.
I have encountered instances where-in a missing communication (forgot to raised red-flag) has put a particular feature on hold on the release date, an inaccurate comment has portrayed requirement conversely (specially in case of offsite-onsite model), not being a good listener has converted a discussion into a heated conversation. After all, a requirement journey to becoming a feature of application requires multiple discussions which eventually needs communication.
Never hesitate in asking questions, discussing or talking with anyone.
Good communication is the bridge between confusion and clarity. ~ Nat Turner
Risk Assessment
Assessing Risk is, under-rated yet essential skill, required at first stage of requirement gathering. Risk assessment can be done in form of understanding how the feature can impact business from revenue, technical, user-experience angles.
For example, changing login mechanism from vendor 1 to vendor 2 include
a) risk of user loss :
- if user is forced to reset their password
- layout of login/signup/forgot password is completely revamped
- user accounts are clubbed in case they had multiple accounts.
b) risk of unsuccessful migration :
- data schema/model of vendor 1 is different from vendor 2
- due to contractual agreement, complete information is not provided by vendor 1
Hence, being a tester, contributing at early stage by understanding the upcoming feature and highlighting the risk, if possible, is expected from you.
Adhering To Processes
Process - a series of actions or steps taken in order to achieve a particular end.
As the definition suggests, it's all about actions or steps but to be taken sequentially and without skipping. In current days, it's difficult and many a times, pressure is there from management to do product release delivery at the earliest. However, it's up to us to buyout time and express the need of processes, time to time to our peers.
Processes will include requirements discussions, technical review of feature, test scenarios discussions, avoid workarounds on final testing, bug triage, UAT walkthrough, deployment release notes and sprints retrospections. Avoiding/Skipping actions is common but adhering to them is crucial.
If you quit on the process, you are quitting on the result. ~ Idowu Koyenikan
Accepting Mistakes
Accepting Mistakes is hard specially when it is a critical defect being missed on production. Being a sole member or team to ensure 100% quality in softwares is very tough, especially with every changing requirements, customer feedbacks, competitors sites creating same functionality in much interactive way and not to forget n numbers of code commits due to distributed micro service architecture.
Hence, to deliver quality by focusing on what being developed and it's side effect is really important. Skipping a single configuration or not thinking about backward compatibility results in mistakes. These mistakes are identified by doing RCA of defects on production and keeping notes to avoid this in future.
Learning from mistakes, understanding where ball was dropped and keeping your head high is important ( and necessary) otherwise doing repetitive mistakes leads to loss of trust, disbelief and fear for the software running on production.
We learn from failure, not from success! ― Bram Stoker
Understanding System/Technology Stack
Do you know testing a project without knowing the underlying technology stack or system architecture, is just like turning on TV, navigating through few channels and turning it off. Sound too simple, isn't it.
In modern days, with large complex systems (monolith or micro services based), the scope of testing and coverage has increased. For example, sign-in/out flow may be integrated with 3rd SSO provider like Auth0 or social logins (FB, Google). Now, without knowing how our system communicate with them, will result in skipping integration failure scenarios. Another scenario can be display of product list on website, which is fetched from API gateway, which further is integrated with multiple sellers of these products. In case of failures at any point, if we are not aware about system architecture, we won't be able to identify, debug or test this case
Embracing Programming
Programming, Coding & Debugging is developer's job. - Why should I care about it? Why tester needs to know programming at all? Such questions are quite common and even I have experienced same.
But the answer is to test our system thoroughly, uncovering cases which are not possible by just doing blackbox testing. Also, when it comes to test automation, writing/validating databases queries for ETL systems, doing performance testing, identifying security vulnerabilities.
Your testing skills can be excellent and are independent of your programming skills. Thus, embracing programming is an optional thing. However, having things, that will strengthen your skills isn't a bad thing. It will sharp your testing mindset, giving you directions to perform advance analysis, which in turn, will assist you in uncovering new testable areas.
Continuous Learning
Ultimately, it's all about learning and doing things consistently. Same goes for Software Testing. It doesn't limits to one specific domain or technical skill or direction.
I believe, doing testing is way more dynamic, diverse and challenging.
Seeing the technology revolutionising day by day, there is no way that learning will cease.
In any of the arts, you never stop learning. ~ Claire Bloom
