Interview With Laveena Ramchandani
Laveena Ramchandani is an experienced Testing Consultant with a comprehensive understanding of tools available for software testing and analysis. She aims to provide valuable insights that have high technical aptitude and hopes to inspire others in the world through her work.
Laveena holds a degree in Business Computing from Queen Mary University of London and regularly speaks at events on data science models and other topics as well as blogs, hosts and trains future testers. She is also a finalist for the Digital star award at the FDM every woman’s award 2022.
As an avid traveler I think it’s pretty cool you work in the airline industry. What are the most interesting parts or what surprised you about testing in the airline industry?
I have had various years of testing experience in different industries, from oil & gas, transport, consulting and airline. It has been a great ride for sure, so much to learn and acknowledge!
In terms of working for an airline firm, from the few months I have already been there I feel like it’s such a dynamic environment. So much to think about, so many things to deliver, innovative ways of thinking and optimizing how the airline performs.
Testing wise what makes me quite happy is that the quality mindset is within each team!
Depending on each project the testing strategy is created on their specific deliverables. I personally feel my role has allowed me to grow and learn so much from an organization where testing is something many people are advocating and spreading eminence for. I currently feel very inspired therefore continue to enhance my skill set.
I have worked in places where testing has been in place from the very start and when I join as an experienced I can only do so much to continue delivering, however a space where you get given the trust and the stage to explore, what can I say? I absolutely love it!
Regarding test strategies, what do you think are the most important things to consider? Any tips for people writing/coming up with their first test strategy?
I have made nearly 3-4 test strategies in the last few months, I really enjoy making them as there is so much more to learn about each and every team and the projects.
Before thinking of a strategy go do the following:
- Understand what you are testing?
- How are you and your team testing?
- What are the outcomes?
- What tools are you using?
- What is the process when raising defects?
- How does your team handle risks and incidents?
- How many environments does your team use when it comes to testing?
- What types of testing do you do, is it functional or non-functional or a mix?
- If something does go wrong how can we rollback?
In my opinion there is no perfect template for a strategy, the important task is to make sure that the right information is mentioned and can be shared.
Tips that I would like to give before making a strategy would be to research, communicate, collaborate and pair within your team to understand how everyone works and make sure everyone is on the same boat.
How did you get started with accessibility testing? Can you recommend any resources? Were there any parts you found particularly difficult?
Absolutely love this topic! I started accessibility in a very odd situation, I was rushed into a meeting and asked have we done accessibility testing once the banking app went live! I was so confused and started thinking what is accessibility testing.
That experience really pushed me to learn about it all and make sure wherever I go I keep sharing the knowledge. I got told once we shouldn’t do accessibility as we are delivering a b to b project and not a b to c. That really shock me and I started moving things forward regardless of what I was told. YOU will face this at some stage in your lives, if you see someone who lacks knowledge, go ahead and share that knowledge as you never know you may save a firm from a juicy fine!
Resources I would recommend:
- Understand the WCAG standards
- Try the chrome plugins (Axe, developer tools, Lighthouse)
- Explore WAVE, Arc Toolkit and screen readers
- Follow the community leaders who are experts for accessibility
- Book: The Design of Everyday Things by Don Norman
- Start checking your front end apps!
Difficult parts within accessibility for me were to understand what particular things meant, specially the errors such as ARIA, page formatting errors which were straight forward for a front end developer. What I started to do then was to pair up with them and learn. As I always say “Pairing is caring”.
For a team that already has a built-product, are there any quick wins for accessibility that could be added?
As I explained earlier, I worked in a team where the product was fully built and stable but no one had done a11y tests on it. You can start looking at colour contrasts, quick audit reports from the chrome plugins. Start coaching your team about it, show them your findings and how these could be improved and in turn the product could be socially aware and reach more individuals.
Step 1- ask your team about accessibility
Step 2- do some quick checks
Step 3- Present them to your team
Step 4- Start adding them to your backlog
I see you used to work at Deloitte - one of the big 4 accounting firms. To be honest, I didn’t know they had testers. Is there a difference to how Deloitte had consultants (that you knew of) compared to other large IT consultancies like IBM etc?
Yes I have, it was a great experience. I remember when I got the offer I was jumping up and down! Testing in a consultancy versus firms like IBM is quite similar. I did not see anything different other than titles as some of my friends were working in non consulting firms.
I think the best answer here would be it depends. As consultants testers have a client to work for and provide their testing abilities to. In my case, when I was at Deloitte my team was based onsite developing products in an agile fashion and I made sure to be involved as soon as possible as a tester. This is where I was testing data science models and experienced that this is an area more testers need to be involved in.