Quality software will never happen from testing alone. It needs a quality culture behind it during the whole development lifecycle.
Poor quality has no place nowadays. In the beginning, you could release a buggy program knowing the users will have to tolerate it because there weren't many options. Today’s customers will never accept this. They have too many options to choose from and they will find a different one! This is why companies can no longer ignore quality! Originally testing was part of an engineer’s job but with the increasing complexity in software and the need for faster release times, the industry realized developers can’t afford to do all the work and people specialized in testing were required. As testing became an integral part of the development lifecycle so did the required skills to be a quality testing professional. Testing is no longer enough. A Q.A. professional must be able to foresee the risk and explain its impact on the organization. He must be able to drive the change needed for quality to be obtained. A Q.A professional knows quality is subjective. For every user, quality means something different. Another thing you need to know is that quality changes over time. Remember when a webpage took 30 seconds to load and we were happy when it did? Now if we have to wait just 5 seconds we are already annoyed.
Let’s talk a bit about the impact of poor quality.
Releasing a bad product has an impact on all levels. Everybody involved takes a hit in a way or another. A company can lose millions. People tend to be discouraged because let’s be honest nobody wants to work on something that is failing. A company’s culture shakes depending on how big the impact is. Your product is what makes and breaks your business. To be able to succeed in the market the company needs to have a quality mindset. It’s not a tester's job to make sure the product is release ready. It’s everybodys. From the moment you think about what you are going to build you need to take quality into account. Starting with a quality mindset is a lot easier than fixing the problems later on and refactoring everything. Planning for quality also means knowing what you build will bring value to the clients. A product nobody needs has no quality no matter how well it was designed and implemented.
Now let’s talk about the actual testing.
More and more people consider automation to be the silver bullet that saves the day but let me share a few thoughts about why it’s not. When thinking about automation have this in mind. Each type of testing is different. You can have a test that verifies something. In this case, you know what the software should do so you just go and check that it does that. Exploratory testing shows you what the software does in certain situations. This requires creativity, something a computer can’t yet imitate. You might start on what path and notice something that leads you down a different path and there is an actual issue there. You could probably automate the first path, but the computer won’t know to go down the second one and find the problem. Having an automated test suite is great and brings a lot of value but you can’t and shouldn’t automate everything. When starting to automate your testing be sure you take into account the value and cost of automating a certain test. Automating things that constantly change in the product might lead to more test maintenance than actual testing. Automating a test that will be obsolete in 3 months might not be worth it altogether depending on its complexity. Take into account how long the process of automating the tests will take compared to how long those tests will bring value. Because different types of tests provide different information a test strategy needs to be designed to validate the product at all stages of development. Unit tests tell you if you wrote the code you wanted, and it does what it has to. This is in the hands of the developers and it’s one of their best tools for validating their work. Continuous Integration lets you validate each build knowing your new code works without breaking another part of the product. Regression testing makes sure the changes in each build don’t affect the functionality in the previous one. Acceptance testing tells us if we built the feature we wanted and that it does everything it’s supposed to. Exploratory testing shows us if there are any issues we are not aware of in a place other types of tests don't check. User Feedback, Yes this is a type of testing! tells us if we developed something our clients want and use. Testing in production can have great value but to be able to do this, everybody needs to have a strong understanding of best practices and you should have a good delivery pipeline in place that lets you roll back any change easily without impact. Knowing this you can decide what type of testing is needed at what stage of the development lifecycle and lets you prioritize each step based on the value it brings. Only with a blend of different approaches and testing strategies can a product truly prove its quality. Skipping steps could mean skipping bugs which could have huge consequences down the line.
Knowing all this let’s see how you can influence others to adopt a quality mindset.
A culture shift can’t be done overnight. People need to understand why quality is important to believe in it. To influence this in people you first need to know your audience. The list of people you need to influence can be long. This is why you should start by finding out who is on it. Look at your peers, your manager, or other teams and see what their goals are. What challenges each face and how a quality mindset will help them achieve them. Find out why they might object to it so you have all the arguments you need when the moment comes to make your case. Once you have the answer to all these questions, you’ll see how different people need different motives to change their mindset. Use this to help frame the issue in terms they can get behind. Instead of talking about features tell them about the benefits your idea brings and how it relates to their issues or objectives. You might need to talk about the development process and how better quality can benefit the overall workflow and release cycle. You might need to point out how implementing your idea could save the company money. Whoever you need to influence will always be more receptive to the idea of change if it brings some kind of value to their goals or objectives directly.
Remember!