Testing Challenges and Trends (2019)

Testing Challenges

Testing Challenges and Future Trends

With the paradigm shift from iterative models to agile technology and now DevOps, there are so many testing challenges are arrived. In this blog, we explain several testing challenges and future trends.

 

Technology is becoming omnipresent

There is hardly any discipline today that is untouched by technology. Also mobile, social, cloud, and analytics-based computing will continue to engulf all new areas that technology is seeping into.

 

Continuous integration and delivery will make the development landscape completely dynamic, forcing the team members to be in an ever-ready state to take on tasks on demand. Such dynamism is not just individual driven but also process and effort driven, making this the most important trait for the entire team to inculcate in the coming times.

 

App Development and Testing Will Soar

Mobile app development will reach newer heights. As of October 2015, just in the U.S. Apple Store, the number of active applications to download was close to two million.

 

While games, education, business, and entertainment are some of the top categories for app development, newer areas especially such as healthcare and fitness are all soon catching up. The market is very bullish where anyone with a novel idea can see it take shape with ample resources available to build the application.

 

That being the case, these numbers will only continue to soar—app development will not stop with just mobile devices. Wearables and augmented reality powered devices will also bring in their own apps, making this a huge market.

 

Testing will have to align with this growth since in many cases even leading retailers may choose to offer just an app rendering rather than a web application.

 

All of this calls for a completely different mobile strategy—the one that is very collaborative to pool in devices and other test resources at short notice, even requiring a very active pool of crowd testers to be maintained.

 

More than the test effort itself, the testing teams will have to showcase a state of being ever ready as most test passes may even just last for a day or so.

 

This is something we are already seeing today and will continue to intensify in the coming times, making it inevitable for testers to be on their feet and able to take on tasks on demand.

 

Paradigm Shift

With the paradigm shift from iterative models to agile and now DevOps, there is a sea change in the go-to-market strategy with a lot of emphasis on quick, reliable releases and continuous delivery. This results in a lot of forwarding and backward integration in the overall development processes to ingrain agility, flexibility, and reliability.

 

A lot of new tools and path-breaking practices are being developed around continuous delivery to find every possible way to optimize the overall development and delivery process.

 

Keeping in line with this, the QA function all together is reinventing itself. But this is also bringing up questions about the QA function: Is it an impediment? Or a necessary evil?

 

Or an enabling and value-adding function to the overall development process? This case study provides insights into one such client where the QA function has gone through a strategic change with the changing times and needs.

 

Production Challenges

Production releases frequently rolled back: The product platform is huge and complex, with a lot of integrated components, communicating with each other.

 

Development and fixes to one component need extensive testing across the full platform to validate any impact. Most components have ongoing changes handled by separate project teams.

 

Comprehensive regression tests for the platform before any release had become inevitable. The rush against completing the extensive platform regression tests within available time resulted in leakages and production rollbacks.

 

Reliability of regression tests:

Due to the enormity of tests and lack of a directly visible linkage between requirements/features and tests, confidence on regression tests was low.

 

Also, with ongoing sprints, there was never a time when all tests could be run on the final build. There was always a huge freeze period on staging to enable running tests and fixing defects, thus thwarting integration of newer developments.

 

Repeated elaborate deployment planning and delayed production deployment schedule: 

Due to the enormity of the platform with a lack of integrated build process, deployment planning always came out as a mammoth task—this resulted in further delays to the deployment process.

  • Frequent post-deployment issues: With pressure on releases in an agile environment and changes taken in until the last moment, regression tests could never be reliably executed resulting in defect leakage.
  • Go to the market of newer features/products were mostly not deployed on schedule.
  • Lack of collaboration between product owners and engineering teams led to confusion around requirements and deliverables.

 

The challenges discussed here were actually symptoms to a deeper problem. Though the overall development methodology was agile in nature with a focus on continuous customer value creation, the QA function was not developed and equipped enough in its approach and strategy to support the agile structure.

 

Reliability and Quality Challenges 

The change in QA approach over the last 2 years not only highly increased the reliability and quality of the production deployments but it also significantly helped in expediting the QA process, bringing in very short but effective QA cycles.

 

This further led to the quick and early detection of defects, thus resulting in faster deployments. The case mentioned earlier brought in more confidence in the QA function, helped the product get a quality facelift, and also boosted the team’s morale and positioning as a whole.

 

As testers, it is exciting to see what the future beholds. But this is also the time to take stock of the trends and prepare ourselves to brace such changes.

 

Test Automation

Rather than seeing test automation as mandatory if we as testers understand the value test automation brings in, in the current times, we will appreciate the need for it better and start leveraging it on our own.

 

That will be a true win for software quality, for our careers, and for the overall industry rather than forcefully having our managers thrust test automation on to us. Such a positive move from the fraternity is what we really need at this time. So, why has really automation become so important at this time?

 

A study shows what respondents have to say with increased test automation—72% say there is better detection of defects, 70% appreciate it for better test control and transparency, 69% recognize the shorter test cycles, and 66% give it to better test costs.

 

Whatever the kind of tester you are on the team, now is the time to consider taking on test automation in possible ways, whether it be for product quality or for process and productivity improvement, as this is going to make all the difference in software testing in the coming years.

 

With more test automation, continuous testing and quality are made possible, the dependency on a given tester is going to be brought down, and testers can refocus their priorities to taking up bigger and better areas of work that call for their core testing expertise and mindset. The good thing is that the test automation technology and tool landscape have become very open.

 

Having an understanding of any one programming language and the core testing fundamentals and an experience of using one tool, one should be able to fairly and flexibly adapt to newer test automation solutions.

 

In several cases, for instance, even in our company at QA InfoTech, we leverage traditional automation engineers to build test frameworks, after which nonprogramming test engineers are able to take on test automation by using behavior-driven test approaches.

 

Such newer approaches empower the large testing community that may have been so far comfortable only with manual testing, to take on automation with ease and without any inhibitions. This is important in the coming years as we prepare ourselves for the future.

 

Will Manual Testing Cease to Exist?

This is a long-debated question. The focus keeps changing from one to another, but at the current time, we have fairly stabilized in our test engineering processes and their alignment with the development cycle that we can say with certainty that manual testing will not cease to exist.

 

Manual testing will further be elevated to become a niche—a niche where the focus will be on newer testing techniques that primarily look at end-user expectations; additional coverage scenarios that are brought in, in an exploratory manner field; and in-house studies that look at nonfunctional test areas such as usability and accessibility.

 

Manual testing will be increasingly left to the more experienced testers who are able to look beyond the core requirements in not just evaluating the current product but also offering suggestions on its potential future implementations. It will become a proactive test cycle that simultaneously brings in requirements for subsequent considerations.

 

Entry- and midlevel engineers who are into manual testing today should understand this to get themselves ramped up on test automation, as clearly we will see more and more of automation, in the basic test layers in the coming years—whether this be automated build verification tests, sanity tests, regression tests, and so on.

 

Also, while the knowledge of a programming language is a huge advantage in picking up test automation skills, the lack thereof doesn’t necessarily restrict one from working on test automation.

 

Today, there are ample test automation frameworks, tools, and utilities that enable amateur automation engineers and manual testers to step into the test automation space.

 

This would be a good place to start with and gradually ramp up on a programming language that best meets the needs of the work that the tester is involved in. In addition to this, once a manual tester, you are always a manual tester in some sense.

 

So even if you move to test automation, you will see this in a positive light where you are able to automate scenarios to increase your productivity and coverage and be able to simultaneously free up some time for out-of-box manual testing.

 

Also, areas such as bug bashes, session-and charter-based exploratory testing, and crowdsourced testing are all becoming very valuable in bringing in more test coverage—these are tasks that are best done manually.

 

With the increasing focus on end users, competitive positioning, and shift left approach to engineering, manual testing will soon elevate itself to the niche that will coexist with test automation.

 

Do I Have to Be a Domain Expert?

The days where a tester could say, “I understand test strategy, planning, design, and execution; give me any task and I would be able to take on the test effort,” are far gone.

 

Such a generic tester can still exist today but will not be able to thrive. He will merely survive. The domain knowledge of the industry that a tester works in is becoming increasingly important.

 

The workflows specific to the domain, compliances, checklists, user expectations, and target market are all becoming important to understand, to tailor a custom test effort that can differentiate the product in the marketplace.

 

Since the organization anyways has the domain expertise, it is not going to be difficult for the testing group to access the right resources, to ramp up on the domain knowledge.

 

However, oftentimes the domain scope is very large and the domain experts may be too deep into the subject that they may not be able to get to the basics of the knowledge sessions.

 

In such cases, the team can look at having an official training imparted for their group and also target some domain-specific conferences to attend as such forums have a mix of expertise levels for them to pick from.

 

You may not need to become a domain expert, but being privy into the latest domain’s core fundamentals and leveraging them as required in ensuring app quality is becoming inevitable—both for the tester’s performance and the product’s quality.

 

Is Independent Testing Dying?

Amidst all of this buzz for upstream quality, increased collaboration among team members, freelance app/mobile development, and collective ownership for quality, while it is exciting to see more people partake in contributing to a quality release, the underlying concern that cannot be ignored is whether independent testing is withering away.

 

As testers, it has taken us a long time to establish the status of independence in testing—a status where there are unbiased test coverage and evaluation done by a group of people who have not been involved in product development, at least in the given release. ISTQB calls independence a range rather than a condition, swaying all the way on the spectrum from “no independence” to “full independence”:

 

  1. At one end of the spectrum, the absence of independence is where all testing is done by the programmer.
  2. Moving along, we have integrated testers—who closely collaborate with developers and report into the same development manager.
  3. Further along, you have testers working outside of but with development and reporting to the same project management office.
  4. At the extreme end, you have full independence, where testers report to a completely independent business head.

 

All along these four range positions, outsourced test vendors can really fit in anywhere in the spectrum. When independent testing first evolved in the late 1990s, testers moved from state 1 to state 4 directly in this spectrum.

 

Now, we are gradually moving inward into states 3 and 2, which is why the fear of whether we will or we have lost our independence.

 

Undoubtedly, there are organizations that have a merged role of developers and testers, where people assume cross functions. So, is independence really lost in such cases?

 

With due care and execution from the testing fraternity and sensitization of the product team, independence can be retained and resurrected in these challenging times. This is going to be very important for the coming years as software development landscape changes significantly. Let’s see how.

 

Independence Need Not Come in Just from Testers

We often think the independence factor comes in only from the testers, whereas in essence, it can come in from anyone who has not directly worked on coding the module under test.

 

It could thus be designers, build engineers, business and marketing team members, external team developers, end users, crowd users who are testers, users or domain experts, etc.

 

When such a strong independent team is put together in addition to the core additional test team, the unbiased evaluation is able to cover new scenarios, in a shorter time and lesser cost. Freelance developers also need to understand this, as studies show that the average shelf life of a mobile application is only 30 days.

 

Given the time and effort that goes in such development, you would agree that is a dangerously low number. If this has to be improved, independent and unbiased testing is important.

 

Also, even in teams where there are no testers, at least a round robin style of development can be adopted where one may be a developer in the current release but a tester in the next and so on.

 

Understand the Dotted Line in Role Delineation between Developers and Testers

A couple of years back, one of our employees had written an article for a leading software test publication on this topic. 

 

While collaboration between testers and the rest of the team is inevitable and valuable in its own ways, it is important to tread the thin line of distinction between developers and testers very carefully, failing which there is a good chance of team morale issues, impacted product quality, role trespass, etc.

 

It is thus important to identify areas where such sensitivity and role ambiguity exist and play carefully.

 

For example, a tester may sometimes be required to suggest solutions for the defects filed—herein, he may be expected to make some small changes especially in content files for locale fixes. Similarly, he may be required to help the developers identify unit test scenarios, take on static code reviews, etc.

 

Likewise, developers who are using the test automation suite may notice areas of improvement to work on. All of these are sensitive touch points where the entities should be careful to ensure they do only the bare minimum that is required. Anything over and above will dilute their focus and waste their time and may also create insecurities among team members.

 

Understand What Role a Tester Should Assume at This Time

As part of maintaining independence, if testers understand their core role and the add-ons that will help bring in value, we can rest assured that the independence can be preserved for the immediate present and into the future.

 

Herein, the tester has to appreciate the need and importance of test automation, understand where manual tasks come in handy (especially in cases of nonfunctional testing such as performance, security, usability, and accessibility), and test centers of excellence and how each of these will help them tie in their efforts to the overall product quality goals.

 

With care taken on these fronts, independent testing is here to stay and for the right reasons to uphold product quality and the tester’s career. Other Additional Best Practices to Adopt to Empower Ourselves for the Present and Prepare for the Future

 

Stay Hungry, Foolish, and Continuously Challenged

This is an adage that became very popular when Steve Jobs quoted it in one of his last public speeches. In today’s world, amidst the constraints we work within, staying hungry and foolish is even more important.

 

It can help you stay challenged in your testing career for advancing in your professional and personal growth. Given how dynamic the technology landscape is, the ongoing culture of learning and staying challenged is what will make all the difference in the coming years.

 

Adopt Continuous Improvement

A mere desire to learn and not knowing how to go about with it will not get the tester very far. In the self-managed teams that we are working in today, the tester needs to devise his own plans to embrace continuous improvement. The best way to achieve this would be to regularly introspect test processes; evaluate how other teams are working;

 

keep tabs on latest in the industry through news feeds, forums, and conferences; and evaluate which would make sense for him and the team. While this is connected in one way to the earlier point, this is more focused on an actionable set of practices rather than the desire to stay hungry.

 

The “Ante” for Products

Every industry has standards, best practices, minimum viable launch criteria, or whatever you want to call the “ante” to just get in the game. These are the “whats” of software testing.

Software needs to be

  1. Reliable—Does what is expected, when expected
  2. Responsive—Got to be fast
  3. Available—From just about any device, from just about anywhere, in just about any language, even if I am disabled in some way
  4. Maintainable—Needs to be built for change because the world is not standing still
  5. Secure—Both my device(s) and my data

 

This is an important list, but not in any particular order.

The plethora of tools and practices that allow us to meet the minimum expectations of our users and of the industry is exploding and that trajectory will likely continue into at least the near future. For example, testing automation has permeated every aspect of functionality.

 

From the user interface to APIs and business logic, from accessibility and usability to performance, and from services layers to deeper levels of unit testing, automation has become an integral part of the architecture and delivery process.

 

In some organizations, builds and releases are being automated to create an ability to deliver software in a continuous steady stream just as fast and programmers can churn it out. In fact, for those continuous delivery organizations, full-stack automation is the backbone that makes it all work.

 

The Cloud, the Crowd, and Distributed Teams

And then there is “The Cloud.” The trend towards commoditized technologies has leveled the playing field such that start-ups can compete with the largest international conglomerates; a brave new world indeed.

 

The glass windows of the isolated data center have all been smashed. The special access of the “Super User” is available to everyone now.

 

A lot of the skills of the SysAdmin have been abstracted into a relatively user-friendly AWS interface. Almost anyone can build out a computer system with “virtually” unlimited scalability and speed. With Moore’s Law still in effect, infrastructure technologies are becoming more abundant.

 

People and teams are all over the globe. Crowdfunding and crowd testing are crowding the market. The cloud, crowd, and continuous delivery are as much about technologies as they are about collaboration, coordination, and effectiveness with people.

 

The cloud may be the place to get things done, but the challenges of time zones, languages, norms, standards, and expectations impinge on the inter-personal trust levels that teams need to move at the pace of today’s business.

 

Teams need to quickly build trust and the ability to communicate, coordinate and collaborate effectively across the globe. This presents challenges we’ve never had to face before.

 

Many of these trends are already well known, so what is new and different? Keeping up with technology is a bare minimum, but what, as a professional, should I concentrate on learning in order to stand out with my peers?

 

In the past, in general, teams worked in one geographical location. We found help from our trusted network of people with whom we had worked. The world and our projects are far more dynamic now.

 

More often, we need to find unique specialists for our team who can be trusted to deliver and we may never even meet them face to face. We need new criteria for deciding with whom we want to work and our criteria need to include their trustworthiness as well as their technical prowess.

 

Mobile First Workflows

This requires a change in mindset and the tools being used. As mobile penetration increases and more individuals start using multiple mobile devices, the workflows will change completely from the way we know them today. Test engineers need to be able to validate these new workflows.

 

Reliance on Community and Social Platforms to Solicit Feedback Proactively

The days of shipping products across the fence and waiting for a few weeks or months to receive user feedback are long gone. With the instant reach of social media, reaction to new versions of applications is instantaneous.

 

Test engineers should not only rely on technical support teams to parse this feedback but also bring in individual due diligence with the abundance of information available today. Such a responsive engineering team leaves a positive impression on the company and product.

 

Another aspect testers should consider here is to leverage easy outreach to customers as a tool to either selectively roll out services and gauge feedback or conduct A/B tests with control groups.

 

Agility in Release Cycles

Traditional release cycles of many months or years have compressed to releasing more frequently.

Agile companies like Faceb release updates to their site multiple times during a day. This requires test engineers to be nimbler in their processes, more judicious about tests to be conducted, and savvier in taking on calculated risks; all of these while ensuring the quality of shipping applications are high.

 

Shorter release cycles lead to challenges like lesser dedicated time for testing. Robust application design, testability of written code, and high bar for quality of code need to be enforced to be able to deliver quality software.

 

Compressed Duration for Endgame Certification

Applications with a large code base need a dedicated window for integration testing. In projects with annual or greater release cycles, this was easily doable. With multiple frequent releases, this window is now compressed. Test engineers need to identify the base set of tests they will execute.

 

Reliable automation is a must. Focused testing on the areas of code impacted in a particular release should be done. Any risks identified during this testing should be duly highlighted and followed up on.

 

Connected Workflows

Gone are the days where software applications had isolated footprints. Almost every application has a reach outside the core desktop or mobile primary interface. Desktop products are connected to mobile devices and vice versa. Mobile apps rely on services to deliver value to users.

 

Test engineers need to understand all the possible touch points of the application they are validating and perform tests that cover all those scenarios. There are many variables and failure can emanate from any one of the connections. Test engineers need to factor these appropriately at the planning phase itself.

 

Security Breaches

Security breaches and the cost of resultant failures are detrimental to a company’s scenarios. There are many variables and of those is an important aspect for test engineers to build skills—this is now more important than ever.

 

Industry acknowledged certifications and best practices should be studied and implemented as a part of the software development process.

 

Security isn’t the responsibility of just software security teams. Test engineers especially can help highlight issues by including tests specifically around security in the test plan.

 

Wearable Technologies

Wearable technologies are set for huge growth this year. Gaming consoles and fitness devices and tools for specially-abled individuals are now becoming more sophisticated.

 

Testing these devices and applications requires a good understanding of the intended use. Since some of these technologies are cutting edge, there may not be existing benchmarks to compare with.

 

A fine balance between testing on simulators and actual devices has to be drawn and one cannot completely replace the other. Test engineers are encouraged to be comfortable in handling and using these devices like a user would in the real-world scenarios.

 

Internet of Things

With the increase in applications built off the concept of “Internet of Things” (IOT), the testing of these is an aspect that test engineers should be well versed with.

 

Use of common household appliances like washing machines or refrigerators already adopting these technologies means testers need to combine the application of these devices with the technology backbone that supports their “smartness.”

 

Since these appliances are in the home and all-pervasive, security testing and privacy settings are paramount and should be prioritized over other forms of testing.

 

Another example of IOT that is set for an explosion in adoption is driverless cars. This concept is being actively tested in many countries and is set to redefine our concept of owning cars, driving them, and will lead to a new world that we can barely imagine right now. 

 

How to test for scenarios for technology that is still taking shape and with applications that can widely vary depending on the nuances of local geography and demographics will be interesting.

 

DevOps

The lines between traditional IT teams and engineering organizations are blurring due to the nature of connected services and applications. It is difficult to imagine a stand-alone application today that doesn’t rely on back-end operations to support it. DevOps is a great career move for test engineers.

 

In the agile application development world, the turnaround time to design, develop, test, and deploy is shrinking and having an engineer who is well versed with test methodologies is an asset to the operations team.

 

Yes, there are skills one needs to build around tools being used for this function for configuration management, virtualization, app servers, and web servers, but the transition can be easily done. Since DevOps is still an upcoming field, there is a huge demand for good engineers in this field and should be actively considered by test engineers.

 

I’ll end my piece by saying that a trait every test engineer needs to have is the ability to dream. Often in our urge to be quantitative, we lose the edge on thinking out of the box and be creative in approach to test engineering.

 

Concluding Thoughts Summarizing the Sentiments of All Three Experts

In summary of what these experts have had to say, I wanted to highlight a few core takeaways on this question of “where are we heading?”

 

1. The days of BUFT are going away. That said, testing still needs to be up front. It just cannot and need not always be big.

2. Compatible test matrices cannot be fully envisioned and tested for up front, by just an internal test team. The testers will have to spearhead the effort in unison with end users who are also brought in as testers.

3. The experience in coding makes a tester even better.

4. As a tester, you have several other entities that are also taking part in a quality effort. You need to manage commitments as a tester to get the job done at the end of the day.

5. Continuous delivery will become the norm and not the exception in moving forward.

6. As testers, you will increasingly work toward helping teams innovate and build a competitive advantage.

 

Analytics

This is certainly going to be the future for many more years to come. Today, it is all about user data. The volume of data handled in a sheer span of 60 seconds is mind-boggling.

 

In 1 minute, e-mail users send 204 million messages, Amazon makes about $83,000 in online sales, and Apple users download 48,000 apps. On the social front, Facebook users share 2.46 million pieces of content, 277,000 tweets are tweeted, and Tinder users swipe left or right 416,667 times.

 

All of these data are very valuable when analyzed and processed to bring relevance to the core business. Organizations have started understanding this and a lot of emphases is placed on analytics and big data to ensure the data are put to meaningful use.

 

What this means is the tester now needs to understand how to test for such large datasets and ensure the right test coverage is obtained within the constraints of time and cost.

 

The industry as a whole is grappling with testing big data and what tools to leverage, both to handle structured and unstructured data. From our experience, tools such as PigUnit and Hive under the larger Hadoop umbrella are the more popular ones that testers lever-age today depending on what their usage needs may be.

 

Social Media Cloud Analytics

Gradually the industry has gotten used to handling social, media, analytics, and cloud at individual levels. Teams have at varying levels understood what it takes to test them and how to incorporate results from each of those elements into the larger product context, which are all positive outcomes we are seeing.

 

However, the industry is now moving into a newer trend—a trend called Social Media Cloud Analytics (SMAC) that brings together social, media, analytics, and cloud under one umbrella. This is a change at an organization level forcing companies to look for any missing pieces of the pie and fix them.

 

For example, a given organization may have a strong mobile, analytical, and cloud presence but may miss the social piece. Now is the time such gaps are being taken care of. What this means for testers is 24 * 7 availability to address issues that surface.

 

This stretches beyond the bounds of core testing and forces them to constantly evaluate information flowing in from users and how they are faring against competition and release live updates and patches on the go. The year 2014 had some interesting statistics to show.

 

Seventy-six percent of businesses were using social media to fulfill their business goals, 72% acknowledged enhanced productivity through smart device adoption, 75% were focusing on leveraging analytics, and 92% were satisfied with outcomes from their cloud implementations.

 

These numbers are only going to further strengthen with the integration of these pieces to form the SMAC platform.

 

As testers, we need to continue to look for testing scenarios that tie in these pieces together to train ourselves to think from a holistic SMAC platform standpoint and what that interconnect means to overall product quality and market acceptance.

 

Computing Everywhere, Internet of Things, and Context-Sensitive Systems

The digital world today has become ubiquitous. Mobile penetration into remote parts of the world is on the rise. Internet availability, speeds, and reliability are improving by the day.

 

With such a strong infrastructure presence, businesses are looking at positively leveraging the user base and better connecting with them for relevant solutions. No longer is an isolated solution taking place.

 

Solutions are all coming together whether it be the SMAC that we saw previously or the Internet of Things to bring in smart offerings or more importantly proactive user connect through context-sensitive systems. No longer is the user always reaching out to businesses with his requirements.

 

An increasing trend is to see upsell where businesses have reached out to users with suggestions based on the context they have about them.

 

All of these mean the tester cannot limit his work to just his office premises. He lives and breathes quality even outside his core work hours, as you never know where one may get quality cues from.

 

For example, I may be at a shopping mall or a restaurant over a weekend and may be able to see some live product users and get to interact with them. I may get an advertisement based on the set preferences that may give me cues for my product under test, say when I am vacationing out of the country.

 

It is all about anywhere and anytime computing today and the tester who is able to connect the dots between what he does at work and what he sees outside when he is away from work is the one who will be able to thrive in the coming times. Just drawing the connection will also not suffice;

 

he will have to translate them to actionable inputs that he can get back to his workplace to further enhance the quality of the product and bring in true business value.

 

The aforementioned list though not exhaustive is at least comprehensive enough to give you an idea of what is happening in the current times and how all of these are impacting testing.

 

Other areas such as predictive analysis are also slowly making their way, all of which together are expected to bring in a huge change in the coming years in the world of software development.

 

As a tester, it is important for us to understand and keep track of these to see how they relate to what we do currently and what else we can do differently, to experience ongoing continuous improvement.

 

The interesting takeaway here is that several testing best practices (e.g., think of nonfunctional areas, think like an end user) have all been long advocated in the testing industry—they continued to remain optional best practices all along. However, with the changes happening in technology today, they are slowly becoming inevitable best practices for teams to adopt.

 

What Other Things Are We Doing as Testers?

As a tester, we have come a long way. This period is one of the most exciting yet challenging times that a tester is going through.

 

Those who are able to handle and convert these challenges into opportunities clearly have a strong road laid ahead of them both for the products they are working on and for their own personal careers.

 

What is driving all of this change? The state of product quality today, which in turn is directly influenced by the state of product development, has a lot to do with what and what else we do as a tester. For instance, today product quality is no longer a responsibility of just the testing team.

 

Obviously, if something goes wrong, it is still the testing team’s neck that is out online. But the rest of the teams have also started understanding and appreciating quality in the hope of being able to contribute in possible ways within their spheres of operation.

 

Secondly, the need for domain knowledge is more important now than ever before. As a tester, while my core testing skills of test planning, execution, and defect management are all important, now is the time I can differentiate myself with knowledge of the domain that I work on. 

 

This could be domain-specific workflows, regulations that govern the domain, the market for the domain, etc.

 

Additionally, although there are specific teams such as the business and marketing teams that are chartered with understanding market competition, a tester can add tremendous value in evaluating the current product against competition in areas such as feature set, functionality, performance, usability, and accessibility—all from a quality angle.

And finally, it is becoming important for the tester to think beyond the bounds of his core testing work. 

 

Current Trends That Will Also Set the Base Moving Forward

Trends define what is coming in the foreseeable future. Not all trends may take off at the same intensity, but trends definitely give a great insight to plan for the future and be prepared for what is in store. We are almost at the close of the “current period” under consideration.

 

  1. The technology landscape is very dynamic today.
  2. Application development on mobile platforms will continue to grow.
  3. Mobile-only renderings will soon enter the scene, making desktop-based web applications a thing of the past.
  4. End users will have an increasing role in software development—more crowdsourced testing will prevail.
  5. The existence of independent testing will be challenged but will prevail.
  6. Commercial and open-source tools will coexist and become more collaborative unlike the current time, where they were seen actively competing against each other.
  7. A shift left to understand system internals and a shift right to align with end users will have to be the balance in strategy for a tester to take in.
  8. DevOps will see increasing levels of automation but will continue to embrace manual testing into its fold—manual testers will see an increased need to branch into test automation.
  9. Testing centers of excellence will grow to cross-share knowledge and resources and build on efficiencies.
  10. Testers will be increasingly respected for their role in upholding quality and bringing the team together toward a common goal holding end-user requirements high.

 

11. QA/tester’s toolkit, on one hand, is strengthening but on the other is becoming lighter. This is a great trend to see where the toolkit only has really valuable tools that testers can repeatedly use.

 

Some of the low-value tools are taken a close look at and removed from the set to include tools that are more powerful and oftentimes multifaceted in what they offer.

 

“Is Testing Dying and Will It Cease to Exist in the Coming Years?”

There is no direct answer to this question, except to strongly say that all lies in the perspective of the testing group that is involved.

 

If the team happens to be one that is content with its current style of operations and is complacent or not willing to move on and align with the changing needs, then yes, I can strongly say testing will die soon.

 

But if the fraternity at large and testing teams at their small levels understand the changing facets of software quality and work toward customizing and adopting them in their own spaces of operation in possible ways, the future not only exists but is also bright.

 

Such agility is the need of the day today and into the future to ensure quality is built into the products up front. Today, release cycles have already shrunk from several months to just several weeks for many products.

 

This will only continue to further shrink in the coming years necessitating quality to be absolutely nimble. However, since quality has become and will continue to be collective ownership of the team, the test team will have to create its own value proposition to continue to position itself on the team.

 

Also, they need to take on bigger and better tasks, primarily focusing on continuous integration and delivery, which means more overall automation (both at a test case and at a process level).

 

If as a fraternity we are able to do this, the test will not be a dying profession but definitely a thriving profession with a much better facelift and positioning than what it has today.

Recommend