This was my first time speaking at a tech conference. I have always had cause to speak at small gatherings but not a room of about a hundred QA engineers, QA Managers and QA enthusiasts. It was great rubbing minds with colleagues, making new friends and finally meeting many of the people I had previously interacted with on our online platform.
I was to anchor an idea-focused Q&A session for about an hour. The session was to foster knowledge sharing, exposition on the current practices/activities employed at the various QA teams represented in the audience (whether wrong or right). All of this was done with the sole aim of fine-tuning the quality playbook. The questions discussed are:
- A bug in production/live environment. Who is to blame?
- In system testing, there are three kinds of testing involved, α – testing, β – testing and acceptance testing. In an environment that develops its own product to the public, which type of testing are best to be done and in what order (with reasons)?
- When there are no tickets on the board or when there is no new update or build released to test, what do you do vs what should you be doing?
The audience participated actively during the interactive session. Non-QA professionals were also very eager to share their views on these topics as well. At the end of the session, everyone was able to come to a conclusive decision regarding the topics discussed. My slides can be found here
Asides this session, there were three other talks;
Optimising Product Test strategy in an Agile Process – Kolapo Bankole.
Many QAs find themselves in a very fast-paced environment. Kolapo took his time to explain the Rapid Software Testing methodology emphasizing the need to stop doing things that don’t help but rather focus on the product risk.
Integrating DevOps in Quality Assurance – Ezekiel Udoh.
During his talk, he explained the role DevOps play in an Agile team with respect to the QA process through the adoption of CI/CD/CD. He also explained the C.A.L.M.S framework developed by Jez Humble when attempting to integrate DevOps into QA Processes. He also described the role of DevOps in Shift-Left and Shift-Right testing which was one of the highlights of the conference for me. His slides can be seen here
Quality Assurance Processes in the Banking Sector Sunday Omale.
In this talk, he went through the different phases of the STLC as well as the QA processes recommended by ISTQB. He then went ahead to explain a few modifications and customisations done to these processes in order to meet the peculiar needs of banks.
Here are a few highlights of the things that really resonated with me:
- There is a dire need to have a right balance of both the Shift-Left and-Shift-Right testing approach: While the Shift-Left approach focuses on finding defects earlier in the software development lifecycle by highlighting and removing ambiguities in requirements. The Shift right approach also provides us with the opportunity to continuously monitor the performance and usability of an application in order to better understand user behaviour. The right balance of both strategies ensures the best possible quality apps that meet the needs of our users in a very agile manner. Adopting DevOps in Quality Assurance facilitates this easily.
- Being a technical QA doesn’t only mean you are very skilled at automating tests. It also means that you are not oblivious of the tools employed by other team members during the software development especially with regards to CI/CD/CD tools. This is quite useful, especially when working with agile teams.
- It is very important to know when to draw the line when attempting to attain perfection for our apps when the reality of the business timeline is staring at one in the face. Knowing how to correctly identify the most important regression tests and strategies to employ and activities to skip in such a situation at the same time is always a dicey one and should be learned.
- It is also important to find ways to optimise automation tests. The need to employ more of data-driven testing while automating tests was emphasized where test scripts read test data from data sources as against using hard-coded values.
It was such an honour to share, learn and network at the conference. I am eagerly looking forward to many more opportunities like this.