Why Software QA matters not only for testers and how to get started
Don’t compromise on the QA of your software
Software quality assurance in general is a severely underestimated part of software development. Often neglected, it stuns me how so many developers and companies put so little effort in software QA and testing in particular.
My professional experience with software quality assurance has been diverse to say the least.
I had one employer where software testing was an integral part of development workflow. Until then, I had not much experience in software development and software QA in particular. Continuous integration / deployment, unit tests, integration tests, end-to-end tests, all of these were pretty new and rather abstract concepts to me back then. Seeing how the entire project team incorporated these concepts changed my perception of software QA entirely. Apparently, software QA was not only relevant for software testers and not only used when there was nothing better to do.
On the other hand, I worked in an agile software development project for multiple months where I encountered a very different approach when it comes to software QA. Unit tests? No. End to end testing? What is that, some kind of food? API Documentation which is up to date and explains everything developers need to know? No time for this, we must develop gazillions of features first and fast. CI / CD? Well, the build is working and we’re automatically deploying it so we are doing it, right? As you can guess, this is quite the (unpleasant) contrast to the aforementioned former employer.
Testing is fine and all but is it really worth to put that much effort into all of this instead of actually developing?
Yes, it is. No asterisks, no “but”. I have personally made the experience that the final result and the way to get there are both more satisfying. If done correctly and consistently, you can save yourself and your (future) colleagues a lot of their precious time and some serious headaches. Trust me on this one when I tell you that you’ll be doing everyone a favor if you do this.
A popular argument against testing is that there are more relevant matters on the agenda which should be dealt with. When your superior wants you develop this feature for this potential customer or fix that super annoying production bug, you’ll most likely will not success with “I have to write some tests first” or “Before I do this, I need to document or someone else will not understand my code” (chances are you work in a Feature Factory). In a time where time-to-market is increasingly crucial, testing may seem like a unnecessary and time-consuming thing to do, especially to non-IT people.
As a developer, tester or as someone who is responsible for the project’s success, it should be in your best interest to deliver the best product possible (if not, why are you working there?). If nobody is willing to step up in order to establish testing as a fundamental part of the software development workflow, then you should take matters in your own hands. Change their perception of testing and show them how they and the product can greatly benefit.
When you’re pitching in front of investors and businessmen and you want to showcase your awesome product, you want to avoid awkward moments like your product not reacting to input or your product not supporting Internet Explorer. Now imagine this happening not once or twice, and you come to the conclusion that it would be favorable if existing product features won’t break when you’re refactoring code one day prior to presentation. Being a co-founder in an IT startup, I realized I would need to be the one to establish testing as a fundamental part of our development process.
Enough about theory, show me how to do it!
Alright, here comes the part where you want to see this thing called testing in action. Fortunately, it is actually rather easy to get started as the entry barrier continues to shrink with awesome tools available for developers and even non-developers. In this article, I am going to put more emphasis in end-to-end tests and provide you with a simple example.
- Unit tests are cheap to develop and easy to execute and debug because they isolate failures. For example, Jasmine is a popular choice for JavaScript.
- Integration tests take a small group of units and test their behavior as a whole, verifying that they coherently work together.
- Finally, end-to-end tests simulate real user scenarios which allows you to spot errors quickly. Execution of these tests takes longer and these can be more complex compared to unit tests. On the other hand, end-to-end tests provide a higher validity that your application works as intended. Protractor, an end-to-end testing framework by the Angular team, is my personal favorite for writing end-to-end tests.
For end-to-end tests, I wrote myself a small helper library called better-protractor which relies on Protractor. This enables me to test any web page in plain JavaScript (for React, Vue.js, static web pages) and TypeScript (Angular, my personal favorite) without switching frameworks or having to write my testing code multiple times. This is the setup for the following example.
1. Setup Protractor (in short, run these commands in your terminal: npm install -g protractor, webdriver-manager update and webdriver-manager start.
2. Install better-protractor: npm install better-protractor
Now you’re ready to write E2E tests with ease. In this basic example, I am navigating to a German tech blog, then clicking on the first article and finally scrolling to the social sharing buttons section. For me, the beauty of E2E tests lies in observing test code getting executed automatically.
How we incorporated QA in our development workflow
- Every component and every service has an appropriate unit test to verify they work as intended.
- For every process (e.g. sign up), there is an E2E test (usually written when the feature is close to being done).
- In our coding conventions, we specified that features are not done until all of the tests as well as the full build are running without fail.
- Code reviews are a great way to not only improve the code but also the team’s skills as well. See this article for more information on this subject.
- Unit tests and full builds of the application are run automatically by GitLab CI. If builds or unit tests execution fail, a Slack notification will be sent and the team knows which commit caused this to happen.
- Of course, manual testing still needs to happen. Still, unit tests and especially end-to-end tests provide a high amount of confidence that our application works as intended without having to manually test everything.
Some general advice about testing
Kent C. Dodds wrote a highly recommended article in which he highlights some interesting thoughts that I completely agree with:
- Often I find myself saving time when I put time in to write tests. I agree: you may or may not take longer to finish the initial task, but for debugging and refactoring in the future you will likely save yourself and your (future) colleagues a lot of time and some serious headaches.
- Static typing and linting tools like Flow and TypeScript can get you a remarkable amount of confidence. If you have ever dealt with weakly typed languages like JavaScript, you know the pain. Still, you should not blindly trust these tools either.
- When you strive for 100% code coverage all the time, you find yourself spending time testing things that really don’t need to be tested. While a high code coverage itself is a good sign and certainly desirable, at some point you’re probably only testing for the sake of getting full code coverage.
- You should very rarely have to change tests when you refactor code. Good tests should avoid testing implementation details. Implementation can change but these changes should not break the actual functionality.
These are my humble experiences with software QA. In conclusion, I see testing and QA as an integral part of any software development project and I hope software developers and non IT-people realize the incredible importance of testing and QA in an age of increasingly complex and time-consuming projects. I would love to hear about your experiences.
