There has certainly been an impact of COVID-19 on the Software Testing Industry. There are several areas which I would like to analyze and break down into further detail. Those areas include: resource impact, testing impact, and workplace impact.
The impact of COVID-19 on the software testing industry first area of impact is on resources. This includes both employees and contractors. There have been so many industries that have been significantly impacted, that it has devastated the software testing industry. Four industries that come to mind is: manufacturing, travel/hospitality, restaurants and retail industries. These have probably been the ones that have been hammered the most. If you think about it, it makes sense that these are the hardest hit areas. These industries all require software, and that requires testers. When COVID-19 started to impact these industries, software testers were hit hard. This is especially true with contracting companies who heavily rely on these major industries in providing software testing resources. Typically, the companies will cut the software testing contractors first before software employees are impacted. There is also an additional impact in terms of travel and visa delays, since airline travel was impacted and visa restrictions hampered international travel. Software testing contracting firms rely heavily on resources across the globe and even if the resources were available and had the necessary visa paperwork in place, but if airlines weren’t operating, they wouldn’t be able to get to the customer’s location.
The impact of COVID-19 on the software testing industry second area of impact is on testing. COVID-19 has required companies to change how they support their customers. In certain industries such as insurance and banking, companies have given credits or refunds back to their customers to help them during this difficult time. This has required companies to change how those systems operate, especially to give credits or refunds for their entire customer base. In the United States, since companies are located across states, each state has different rules and governing bodies. This requires that the software testers understand the rules, and that testing has to be specific for each state. This requires time and test data that is unique to make sure that the testing is adequate. It took a while for most companies to wait and understand what the governing bodies required. The good news is that it gave companies time to figure out what changes were needed, so that bought them some additional time before those were implemented. Most companies gave two months worth of credit and reimbursements.
The impact of COVID-19 on the software testing industry third area of impact is on the workplace. The workplace was drastically impacted because of COVID-19. For most companies, software testers typically work within an office setting. With COVID-19, software testers were moved into a remote workforce. Most companies were already capable of working remotely since laptops and VPN’s were setup and operational. Typically most companies already have WebEx, Zoom, and Microsoft Teams available. The biggest challenge in some situations was the impact on the offshore testers. While some software testers already had laptops, that wasn’t the case for all contracting firms. This required a significant effort to get software testers with the laptops that were needed. In addition, there were some software testers who didn’t always have reliable internet, so that required companies to make adequate adjustments to get the software testers with what is needed. Some of the larger firms such as Infosys, have huge offices that have housing available where resources can remain on the campus.
I hope this information has been helpful. COVID-19 has certainly impacted the software testing industry, and I am hoping that it will make things better and prepared to handle current COVID-19 and other pandemics which will occur in the years to come.
There has been a lot of information shared over the past few years about Test Driven Development. Initially it might seem complicated and counter to logical thinking but it actually makes a lot of sense. Test Driven Development is defined as: a software development process that relies on the repetition of a very short development cycle. Requirements are turned into very specific test cases and the software is modified in order to get those tests to pass. In the normal process of software development, code is written first and then tested to make sure that it works.
What is the origin of Test Driven Development?
The origin of TDD traces back to the late 1990’s when extreme programming started. It because more mainstream when Agile came around. By 2006 it had matured and resulted in additional innovations to the process with ATDD or BDD.
What are the steps for Test Driven Development?
Here are the basis steps for TDD:
Write a new test
Check and make sure the test fails
Write code to pass the test
Verify the test passes
Refactor code to make it more efficient
Repeat steps again
What is the purpose of Test Driven Development?
TDD is a process of modifying code in order to pass a test which was designed prior to code being written. There is more emphasis on writing production code than designing test cases. This includes refactoring and helps to have cleaner and simpler code. It helps to find defects much sooner and eliminates the need of rework.
What is Agile Test Driven Development?
All the teams today that use Test Driven Development follow Agile or some form of it like Scrum.
Who is responsible for Test Driven Development?
Typically the person who is writing the code will be the person to write the test cases. I have seen some situations where there is a slight variation and a test engineer writes them but that is not a common practice.
What are the benefits of Test Driven Development?
The primary benefit of TDD is that it helps to eliminate writing duplication of code
Allows developers to capture defects much sooner in the lifecycle
Software is better designed and results in more maintainable code
Helps with teamwork. More people can work on code together.
Less time is spending on debugging code
Helps with code refactoring
Eliminates a significant number of defects
Often results in projects getting completed faster than original timelines
What are the pitfalls of Test Driven Development?
Here are some common pitfalls of TDD:
Forgetting to run the tests
Writing too many tests
Writing tests that are too large
Writing tests that are too simple
Writing tests that are too complicated
Test Driven Development Skill Levels
There are different skill levels for TDD which include:
Beginner
Someone who can write a unit test prior to code creation
Someone who can get a failing test to pass by writing code
Intermediate
Someone who can write a test case for a defect that has been found
Someone who can take a previous test driven development test and further break it down to simpler tests
Someone who can factor reusable elements
Expert
someone who can create a test driven development roadmap
someone who can provide additional guidance and direction to beginner or intermediate levels
I hope this information has been helpful. You might want to also learn more about Behavior Driven Development.
There has been a lot of information published about Behavior Driven Development or BDD. It is counter to what most people are used to so it causes a lot of confusion. It is very popular and a lot of organizations have started to embrace this methodology which results in great success to those who can consistently apply some basic principles. Behavior Driven Development allows companies to shift further left and identify issues much earlier in the process than using the traditional waterfall methodology.
What is BDD?
Behavior-Driven Development is an extension of Test-Driven Development or TDD. Behavior-Driven Development is an approach to build features based upon user stories. You will typically have a product owner that will communicate the expectations for the software in form of a user story. That information will be stated in terms of business objectives or goals. Both the developer and the tester will use this information to both develop and test if these features meet the expectation of the product owner. While BDD is a process, just like any process it requires great communication between all members. What does the product owner want to see? How can that be translated into software features? Are those features really needed or are there other features that might meet business needs. Behavior-Driven Development heavily relies on communication and collaboration which are also one of the key tenants of Agile.
BDD Testing
Behavior Driven Development premise is that the tests are written before the code is developed. In basic terms it tells you how a piece of code needs to be tested. You want to test the behavior of a given feature. It is extremely important to do this first so that you will have a high degree of testing coverage. BDD requires the person who is creating the tests to think about the business scenario. As you build code, you are building a very large repository of tests which can be executed over and over again using tools such as Jenkins. Now you might wonder if the developers are writing all these tests, why are testers needed? Well testers are needed more than ever. Developers are often focused on a small module or piece of code and don’t have an overall understanding of how the system works as a whole. Testers typically have a broader understanding and are usually business subject matter experts. It is important for testers to understand the broader context of the what and why of software and the business intended use.
Three Best Practices of BDD
Discover: The first best practice is the most important one in my opinion. Created a shared understanding across the business and the Agile team of what the requirements are through collaboration. This is a critical step, and one that most Agile teams will overlook and rush to build tests and code. This collaboration needs to occur through structured conversations using specific rules and examples.
Define: The second best practice is to use real world business scenarios and document how the system should behave. This documentation reinforces best practice 1 and 3. The most commonly used framework for defining scenarios is Gerkin.
Automation: The third best practice is to automate the documentation. This will allow the documentation to grow and become dynamic. This process will verify that the system works as expected and verifies best practice 1 and 2. Most teams today use Cucumber to automate BDD tests.
BDD Framework Process
Here is a sample flow of how things work within the BDD framework:
Create a user story with high level functionality
Hold a requirements session and further define functionality with business examples
Define business scenario using Gerkin
Automate the scenario using Cucumber
Write code so that the test scenario will pass
Run additional tests including regression, performance, etc.
Release code into production
I hope this information has been helpful and has provided you with some great information about Behavior Driven Development
Let’s face it, writing detailed test cases takes a lot of time and effort. As a tester, I know this is very tedious work. However, I know first hand there are some tremendous benefits that far outweigh the time involved. It certainly is not easy, but if planned out properly can be done extremely efficiently. You will probably get some push back in certain areas and using certain methodologies but it is extremely important in my opinion. Agile for example, is not in favor over detailed documentation.
Here are 7 Great Reasons to Write Detailed Test Cases
Planning: It is important to write detailed test cases because it helps you to think through what needs to be tested. Writing detailed test cases takes planning. That planning will result in accelerating the testing timeline and identifying more defects. You need to be able to organize your testing in a way that is most optimal. Documenting all the different flows and combinations will help you identify potential areas that might otherwise be missed.
Offshore: If you have an offshore team, you know how challenging that can be. It is really important to write everything out in detail when you communicate offshore so that everyone understands. It is critical to write detailed test cases is no different. Without those details, the offshore team will really struggle to understand what needs to be tested. Getting clarifications on a test case can often take a few days of back and forth and that is extremely time consuming and frustrating.
Automation: If you are considering automating test cases, it is really important to have all the details documented. Automation engineers are highly technical but they might not understand all the flows of the application, especially if they have not automated that application before. Without the details, there is a high possibility that steps will get missed and perhaps that will cause the automation scripts to not be written properly.
Performance: The performance engineers must also write performance test scripts. They also are more technical in nature, but they really struggle to get the right amount of information needed. It really helps the performance test engineers to have document test case steps so that they will be able to create their performance test scripts a lot faster.
Audit: I have had the experience in testing applications that fall within domains which require regulatory compliance such as telecommunications and insurance. These domains require internal and external audit teams to review all testing activities. It is important to have the teams write detailed test cases so that audit will have a solid understanding of what is tested and will minimize the amount of questions that will eventually come back to the testing team.
Development: I have found that having detailed test cases will help the development team, especially when there are defects, to provide additional guidance and direction. This helps to accelerate the fix time and thus the ability to retest and close those defects.
Training: I have found that it is extremely helpful to have detailed test cases in order to train new testing resources. I typically will have the new employees start understanding how things work by executing the functional test cases. This will help them come up to speed a lot faster than they would be able to otherwise.
As you can see, there is valid justification to write detailed test cases. I am sure if I spend more time, I will be able to come up with another 7 great reasons. I hope this information is helpful and will encourage you to write more detailed test cases in the future.
There is no doubt that AI is Transforming Software Testing. Over the years you can see how software testing has transformed from manual testing into automated testing. It now has reached another milestone and is further transforming with the advent of AI. There are many tools today which have started incorporating AI in order to provide a high level of quality. As a software quality engineer, it is important to understand those changes and be able to evolve with the technology. If you haven’t done that yet, don’t worry since the technology is currently in a fairly infant state.
Here are several ways that AI is Transforming Software Testing
AI will transform manual testing. Manual testing is very time consuming and expensive. AI will enable the creation of manual tests and be able to accelerate the testing timeline by running those scripts automatically.
AI will enable testing teams to cover more scenarios and cases. This will identify more defects due to the increased amount of coverage across the application.
AI will eliminate the need for assumptions. Software testers make a lot of assumptions when they are building and executing test cases.
AI will help in using predictive analytics to predict customer needs. By identifying those needs this will result in a much better customer experience and customer satisfaction will greatly increase.
AI enables visual validation. This validation will identify more defects that traditional software testing methods.
AI will help find software bugs much faster and find more of them.
There are several tools that incorporate AI/Machine Learning to speed up the development and maintenance of automated tests. One of those companies is Testim. Maintaining automated test cases can be very expensive and time consuming. Reducing the amount of maintenance will allow test automation engineers to focus on new automated tests and that will add a higher degree of quality to your applications.
There are some AI tools that will complement existing tools that are on the market today. One of those tools is Test.ai. Test.ai leverages a simple Cucumber like syntax, so it greatly simplifies the development of automated scripts.
Some tools do all the testing for you. I know that is hard to believe and I admit I am also a bit skeptical. ReTest helps to eliminate the need to be able to have programming skills. It leverages AI to fully test applications.
AI will create opportunities for software testers to move into new roles. Some of those roles will include:
AI QA Strategy: This role will use the knowledge gained within AI to understand how this technology can be applied to software testing.
AI Test Engineer: This role will combine software testing expertise along with experience in AI to develop and execute testing activities.
AI Test Data Engineer: this role will combine software testing expertise along with AI in order to understand data and leverage predictive analytics to verify information.
I strongly believe that software testing will continue to be a prominent role within IT organizations. I do believe it will evolve and continue to evolve. This will require additional training on technologies such as AI in order to keep up with technical evolution. AI is a brand new technology, so it will require time and resources will need to be trained on how to use the technology effectively.
Creating Predictive Analytics for Quality Engineering
If you are in the IT profession, you know that metrics are extremely important in helping to make decisions. This is also especially true for Quality Engineering teams. 10-15 years ago, testing was primarily conducted by software quality analysts and test cases were executed manually. Most software testing teams were small, and they would run a limited number of test cases to ensure things worked. Using this approach, it was relatively easy to know if there software was ready for production, and that QA manager could pull the team into a room and determine if the software was ready to be deployed. Those times have drastically changed.
Here are a few reasons why software testing has evolved:
There is a lot of software testing tools that enable status reporting
Automation and Performance testing tools are widely utilized
Applications are more complex and tightly integrated using interfaces across multiple technologies
There is tremendous pressure to deploy products quickly to market
Testing applications earlier in the lifecycle (shift left)
Distributed teams
There is a need based upon this evolution to have software testing metrics in order to make better decisions. This data needs to be consistently captured and analyzed. It is important to create predictive analytics so that you will be able to determine the current state of the quality engineering effort and accurately predict what would happen in production.
Quality is required.
Speed is required.
Resources and time is limited.
Decisions must be made.
Software must be deployed to production.
In order for these things to happen data analytics must be performed. A base set of data is needed. Some of those data elements include:
Sprint Velocity
Planned/Executed test cases
Manual vs Automated tests
Defects
Root Cause Analysis
Defect Leakage
Once this data has been identified, it needs to be captured and segregated. When that information is gathered, you will be able to start and see trends. If you are testing a certain application, you will be able to predict how long it will take to perform testing, how many defects you plan to identify, and most likely how many defects will make it do production. Predictive analytics will evolve over a period of years. Many companies have started using AI/Machine Learning in helping perform this analysis.
This is also a continuous process. It is something that is not done once and completed. Additional metrics and more information will be needed. Those metrics will have to be captured and predictive analytics models will need to be created or modified.
Digital transformation requires that quality engineering teams transform how testing is planned, executed, and measured. The key to digital transformation is a focus on the customer. This requires that the quality engineering teams truly understand the business, and more importantly can accurately predict customer behavior. Issues such as usability, compatibility, performance, and security are extremely crucial. Provided these issues are tested, and the results are acceptable, this will create a really positive customer experience. For example, if a mobile application is slow, the customer is not going to have patience and will quit using it.
Predictive analytics can be used for defects. Here is some helpful information that will improve quality:
Type of defect
What phase was the defect identified
What is the root cause of the issue
What changes need to be made so that defect will not make it into production
Is the defect reproducible?
Once this is understood, changes can be made to prevent similar issues from occurring. Using these predictive analytics, overall quality will greatly improve and speed to market will accelerate. It is important to have the right amount of data so that predictive decisions can be made.
