Series: QA in Agile SDLC (#1)
QA in agile ecosystem!
Use UI , API , DB & logs to improve the quality of the application!
As a fresher, I did not have much idea about the field of “Testing” besides the — instinctual at the time — fact that it needs a lot of attention to detail & curiosity. I say instinctual because when I graduated, formal education focussed only on product development.
I am of the philosophy that my role is not just about finding issues or breaking the product. QAs are an invaluable team member when they provide a complete picture of quality for the product to the team. We are not here to point out developers’ mistakes.
I have been fortunate to get opportunities to explore quite a few pockets of building a quality product. I’ll be touching upon the takeaways in each of them as you read ahead.
Fitting into agile product development :
Having worked on both agile and waterfall types of projects, I prefer the former. It creates a necessary set of ceremonies within the project. If these are done right, it will lead to a successful and timely delivery of a quality project. This also means that the team can fail fast.
What is expected of a QA in agile teams :
- Collaborate for requirement analysis with the stakeholders, especially when teams do not have a BA. Also, at times playing the role of a consultant and helping the stakeholders with requirements to solve their business problems.
- You may need to give inputs with respect to improving user experience. It might also be helpful to team up with UI/UX/VD specialists if available.
- Clear and customised communication with different teams of the product is a crucial aspect for a QA.
- Depending on the team structure you might be involved in strategising the testing of the product. This will include both functional and non functional testing requirements. Although we commonly say non-functional requirements, it is not the correct way to view it IMO. If these are perceived as non-functional requirements then they will predictably be pushed lower down the priority more often than not. So, it is better to see them as development activities which will make sure that the product is consistently reliable in the long run. The other way to refer to it can be cross functional requirements.
- Being part of Epic, Story creation so as to share testing efforts required.
- Active involvement in kick-offs and desk checks so that you can provide feedback earlier in the lifecycle of product development.
QA’s contribution in Kick-offs and Desk-checks :
The main objective in these two ceremonies is that the QA should be able to preemptively discuss acceptance testing scenarios of the story in play. All the scenarios discussed during kick-off need to work as expected during desk-checks. Any additional scenarios being discussed during desk-checks are generally an anti-pattern. Hence, we must choose whether to discuss them during desk checks or pick them in the QA testing cycle.
We must ensure that there is minimal overlap of tests in the test pyramid. Confirm that the unit and integration tests cover almost all feasible tests. Make sure enough testing has been performed before signing off the stories. Figure out which areas need exploratory testing.
After being introduced to these ceremonies, I realised that the best part is a more streamlined development and testing effort. There’s a clearer idea of what developers are working on and how long it will take. QAs can discuss comfortably what all testing efforts are already taken and judge for themselves what amount of testing is pending.
Encouraging trunk based development :
- I will not be going into the specifics of what this is. However, I want to share the reasons for its success, i.e. significantly reducing the time taken to go to production. This will give confidence to every role in the team that the branch the story was completed on is the same as that is to be deployed to production.
- Trunk based development entails that we need to have a strong test pyramid and a toggle in place for all features that we work on. All the test layers should have tests for both toggle on and toggle off for the given feature.
- Hence, even if another story is incomplete, it will be behind a toggle and unlikely to affect any other functionality.
Manual testing :
It is an essential part of a QA’s job description. I see it as a functional requirement testing, right after development. There are various flavours of testing styles in it — exploratory, sanity, regression etc. Depending on where you are in your project and its release cycle, you will be performing:
- Regression when you need to make sure the changes are not affecting the existing functionality.
- Sanity when you need to know if the current build is good to go for further testing cycle or release.
- Exploratory testing when you need to go beyond the traditional testing scenarios of the project. This needs some thought behind the functionalities you might want to explore deeper in a given time frame. Utilising your browser’s capabilities (console and network tabs) to the fullest also helps.
- Monitoring logs for any anomalies in the system will go a long way in identifying hidden issues.
- Testing databases to make sure the updates are as per expectation. For example, if data type is correct, or if column names are consistent with business terms and code.
- If mobile testing is applicable, then strategising this testing considering the myriad of devices available in the market and iOS / Android.
Automated testing :
- This is where you automate the most critical and stable business flows at the topmost layer of the test pyramid.
- This should preferably run on every commit to the pipeline so that we get immediate feedback.
- The lower number of tests at this layer ensure that it is cost effective to write, maintain and understand these tests. Also it will have a quicker turnaround time.
- One can also automate visual regression tests to identify quickly if there are any CSS alterations, be it a microscopic or a glaring change to the website.
- Having worked mostly in Behaviour Driven Development (BDD) model of end to end tests, I have an observation to share : The correct way to write feature files is to make it easy to understand in business terms, rather than a step by step guide to each activity performed on the screen or application.
- At other (lower) levels of the test pyramid depending on the feasibility, QAs can contribute hands-on or lead the team to write better automated coverage.
- Unit & integration tests can be discussed during desk checks. The focus would be the kind of tests being written, ensuring that those tests pass/fail as per business requirements.
- We can have automated consumer driven contract tests.
Right from the start of my career I always preferred to automate to reduce mundane tasks. Following feasible best practices while creating the framework and reducing the redundancy at this level of the test pyramid helps keep the automation suite stable.
A way in which teams can keep automated tests from being neglected is by inculcating a practice of fixing the tests as soon as breaking changes are made so that the pipelines are not blocked. The pair introducing the breaking change can fix it quickly.
API testing:
Besides having contract & automated API tests, we can look for some manual tests as well. Knowing the HTTP request methods, response codes, request/response headers, responses can help you verify APIs being built.
Stay tuned for the next 3 parts, where I will be discussing about the lesser explored aspects of quality !!
