Hi again! This chapter will be shorter and focused on how to work with the previous cited tools.
Everyone knows what continuous delivery is, but rarely I found people who understand how much it can help them to speed up a project. I want to focus on that.
Also I will talk about a few good practices every person involved in the project should know to understand how QA works.
Finally, we will see a few techniques to beat the resistance to change, probably the worst enemy you will defeat.
Continuous Integration and Continuous Delivery
First of all let’s describe what is Continuous Integration, in a nutshell from Wikipedia: “it is the practice of merging all developer working copies to a shared mainline several times a day”. The main benefit about automating every test is run independently and unsupervised. It makes easy and fast to test a whole application and assure its quality.
There are a lot of tools that help you to automate all the execution you need to run every test of your project, from the simple cron from linux to relatively new tools like GoCD. I want to mention the most famous tool for continuous integration, Jenkins, is quite easy to configure and have tons of plugins to improve its functionalities. Almost any CI tool has the same components: a server, which stores all jobs to run with configurations and keys; agents, where process will be executed; and connectors which will report all the info of the project to external tools.
The main task to build a continuous integration system is to build a well designed workflow. It is a must to run all the jobs sequentially, ordered by speed and utility, if some fails the others don’t need to be run. After building the project if necessary, unit testing are fast and should cover almost 70-80% of the project code. After that, integration test will assure all the modules of the project work correctly. Functional and/or acceptance test used to be the next, validating end user view. Load tests aren’t often automated, but could be a great choice on high performance applications.
One step ahead of continuous integration we have continuous delivery. When you have automated validations for every component of the project you can try to automatize the delivery. This way you produce software in short cycles, following something like “fail fast, fail often” mantra, giving to your product small but continuous increments of value, with the certainty you won’t add critical bugs to production.
We all agree is hard to have a complete set of tests that cover correctly all the functionalities, it requires good professionals and a lot of time, but, there are some tricks to know which will help us to make the process easier.
Quality involves all
Everyone in a project should contribute to warranty the quality, from product owners, delivering good user stories with a complete acceptance criteria, to developers who should contribute to improve code quality and unit tests.
QA Engineers have an important job giving a global vision of the quality in the project and granting tools to everyone can do his work as well as they can.
It’s a simple concept to describe a correct tests proportion. You should have more unit and low level test than functional or end-to-end high level tests.
This approach considers the high cost of execute end-to-end tests, which need (usually) software licenses, are slow and need to be redefined often. Intermediate layer acts like a service layer tests, can run faster than end-to-end and check more functionalities than unit tests without complexity of the UI.
Working this way you should assume that a failure on high level test is more than a bug in your application, also, unit and integration tests are not working properly and need to be fixed.
Criteria and prioritization
As quality assurance we have to use our common sense, obviously hardly we could test everything in a project, but it isn’t necessary to, need to know your product and focus on most critical paths, and test all code of them.
On the same way, when a bug spot, you should fix first which have a higher usage. This way you will prevent your users having a bad experience on your application.
Security department often is forgotten when time run against you and need to hurry up on your project. Every platform stores a lot of data, and those data are under the regulation of data protection laws, each component you add to your platform has their own vulnerabilities you have to cover to fulfill these laws.
This is especially important to anticipate vulnerabilities on new versions of your other components. We need people with the knowledge and prepared to understand and fix accord to ISO security standards.
Where do I start?
Let’s be clear, it’s really hard to change a business dynamic. Usually, the people in charge don’t want to change the way they obtain their position. Even more if they see QA as a waste of time, or believe their teams are infallible.
The first step is getting all the metrics you can about your project, this may look easy, but there are lot of things to count and lot of them we do not even know.
Look how much time you spend solving issues, maybe you have a support team entirely for these tasks but this could not be the better idea, if you promote speed instead quality and the person who developes a feature is not responsible once it is on production you will never get a professional team.
Time wasted on refactors, analyzing previous components, bugs found on production environment… All of them could be almost completely avoidable with a person or team entirely dedicated to warranty your project will do its job with the best results.
Once you have all the data, analyze where you waste more time. Maybe it could be an “easy” task and your team just need better documentation but usually once you look, you will see all the people have lot of things to improve.
It’s hard work to implement all these methodologies, tools and cover all functionalities with tests but you will get a warranty in a long term. Each change and version will be validated in a really short time granting a high security.
We have to beat the resistance to change and invest a huge amount of time in a live project to assure it has the quality we want. This effort will make your developer team work faster on every release giving more value to your product without risk the integrity of the platform.
In this future, QA members can help on almost every team, to grant daily work improve quality with the tranquility it won’t break the job already done.
I hope you enjoy these articles, helping and encouraging you to start this path.
I started to develop more than 10 years ago. Dedicating myself to the world of QA was a natural evolution to ensure that every project I enlisted in was the best expression of myself.
Now I work as QA engineer in Datio.