Marie Cruz and Samer Naqvi are QA & Continuous Delivery Consultants at ECS Digital, with almost 20 years of QA experience between them. They spoke at June’s Women of Silicon Roundabout in London about tips to make the lives of software testing engineers easier. Here are three big takeaways from their session:
Tip 1: Software testing must be both fast and good
As software becomes key in creating competitive advantages across all markets, companies now do not have the luxury of choosing either speed or quality when developing software. Agile process has matured quite a lot and DevOps has now entered this environment as well. Continuous deployment, continuous integration, and continuous testing are actually the key in enabling quality at speed.
And out of all of these, continuous testing is by far the most challenging out of them. They're primarily a tools-based activity and continuous deployment is a team and tool base activity. Continuous testing requires not only tools and teams, it also requires individuals and services. If continuous testing is done correctly, it is actually the masterpiece in the agile developing processes.
Tip 2: Consider Shift Left vs Shift Right
Shift left is about testing as early as possible. There's a lot of surveys that suggests that the later you find bugs, the more expensive and time-consuming it is to fix them. Just imagine if there's a live bug. How much of your time would be dedicated in trying to fix this bug? The idea with shift left testing is to prevent bugs as early as possible. We want to shorten our test cycles so that we can deliver faster. This is obviously nothing new, but then I would see that this trend would keep on happening this year and many more years to come especially because the business expectations keep on changing.
Shift right is testing on production, and that might sound scary. Why would you do light testing on production? What's the purpose of this test environments anyway? The purpose of shift right testing is because we know for a fact that in life there's unprecedented scenarios that could happen. There are a lot of techniques nowadays that companies are using, like A/B testing or Canary releases. So with A/B testing, we're actually delivering two versions of a feature of our application based on what the customer sees. Customer A would look at variant A, Customer B would look at variant B. We collect metrics based on the performance on which design performed better. The analytics team, would then collect this data and feed this back with the development team. The advantage of this is we're developing something that the customers would actually want.
Tip 3: Contract Testing is Getting Better
A long time ago in a galaxy far, far away, we used to test web applications that were on monolithic application. It was such a great time only dealing with one database and one depository – it made monitoring very easy. But monolithic applications kind of fizzled out when traffic and dependencies increased. Applications then started with lots of microservices lots of dependencies and testing them became much more troublesome. We tried using mock testing, but it was often unreliable. Then we move to using fly dependencies but that was very costly and difficult to maintain. Nowadays, we use contract testing.
In contract testing, we have both the consumer and the provider. The consumer is the service that requires the data from the other service. The provider is the service that is giving that information. That information is kept on in a contract which is kept on a broker, which can be a kind of filing system.
If you are both the consumer and the provider on the same file repository, you can keep them on file or on Cloud, Google Cloud etc. But another option is to put it on Docker containers, which is now really popular.
Client Server is the leading technology recruitment consultancy. We are driven by technology, but powered by people. With more than 300 live tech jobs in the UK and Europe, visit our website to start the conversation