In the early days at Haptik the engineers built, tested, and released software all by themselves. As the company grew and features proliferated, everybody obviously realized that this wasn’t scalable and that developers can’t test their own features. The engineers then started specializing in skill, creating more scale in the development process at Haptik and that is when I made my grand entry.
I joined Haptik in September 2015 as the sole QA Engineer. I was given the responsibility to test our core products which included our apps, web chat tool and machine learning features. Being the only tester at my previous company, I had just the right kind experience and skills; so when I was given the opportunity to assure quality of products at Haptik I was excited. Being the only tester meant I also had to work with every single person in the company to make sure we are working towards the same goal and this was one challenge I was ready to take head on.
Putting everything else aside, testing such a large product and environment is a long and complex process. At a startup which focuses on nimbleness and speed, requirements can come in the middle of development and it is the responsibility of a QA to make sure the existing systems doesn’t break and the new features are build as per requirements and guidelines.
Before I joined the team, testing was squeezed some place in between the end of development and pre-release. After I joined, we have managed to build a culture of testing at different phases of development to ensure quality. Over the months we have learnt and improved a lot of things & still have a bunch to change. Below are some of the things we did built, and in my opinion have worked and there are also some thoughts around what else we can do to improve our QA processes.
Processes that worked:
- Unit testing: This is a very important process to ensure quality products being shipped from development to testing. The developers need to write unit tests for the features being built and need to make sure all unit tests pass before a feature can be send to testing.
- Git process: Another thing of importance is to have a proper git process. We have implemented git flow by Vincent but in general having a proper process around git is very important to assure quality.
- Testing at different phases: It is of significant importance for testers to be involved in different phases of SDLC. We now test at various stages
- Before feature is complete: We try and test at every checkpoint while a feature is being developed. This helps catch bugs while a feature is being developed.
- Integration testing: We now have a staging environment where all the complete features are shipped and we test the app end to end to make sure new features are not breaking other old features
- Before release (production testing): We point our apps to production and test using production to make sure there are no surprises when the apps are released
- After release: Once our product is released we do sanity tests to make sure everything is working as expected.
Issues we still face
- Smaller bugs are hidden behind bigger bugs: We have seen that small bugs get shipped into production because they get hidden behind bigger bugs. This happens because we don’t thoroughly test the feature individually before we call it complete. We can fix this by adding proper testing at different phases of the git flow process that we process.
- Testing time is taking long: As our products get complex it takes more time to test since we need to test all existing features along with new ones. To tackle this challenge we are starting to build automation to save time testing old features.
- Bugs in production not reproducible: We use crashlytics to find out crashes that users face and some of the crashes which occur (although infrequently) are hard to reproduce. At this point we try and reach out to our users over Haptik / email / call to ask them for help to reproduce the issue.
- Smaller bugs are hidden behind bigger bugs: We have seen that small bugs get shipped into production because they get hidden behind bigger bugs. This happens because we don’t thoroughly test the feature individually before we call it complete. We can fix this by adding proper testing at different phases of the git flow process that we process.
All in all below here are some of the things I learnt to become a better QA Engineer:
- Have a deep understanding of the product and the features being built
- Spend some time in understanding who your users are and how they use the product
- Make sure to accept & acknowledge the deadlines before starting the sprint.
- Talk about problems out loud as it helps you think about things in a different way
- Rubber duck debugging actually helps a lot so try it out
- Ask questions, make notes and connect the information people give you to turn it into knowledge.
That being said, we have now started growing our QA team. I would love to hear your thoughts and suggestions around QA and how we can build quality products.
Also don’t forget, we are hiring high quality QA engineers. So if you are interested reach out to us at hello@haptik.co
This post is written by Sanchita Mishra, Sr. Software Quality Assurance Tester at Haptik.
