The power to fail in front of the exact people it was built for.
I break things early and in private, so nobody has to discover them later in public.
Manual
Automated
Embedded
How I work...
Four rules I picked up the hard way and have not found a good reason to drop.
A bug nobody can reproduce is just a rumour.
Rule 01
Applies toEvery defect I log
Costs meTen more minutes
Test the path a user takes, not the path the developer demoed.
Rule 02
Applies toEvery happy path
Learned atConvergence Lanka
If it gets tested every sprint, it should not be typed every sprint.
Rule 03
Applies toRegression suites
Built withPlaywright and Selenium
Nobody enjoys hearing their work is broken. Say it with evidence and no blame.
Rule 04
Applies toEvery stand up
WorthMore than being right
2 years in QA
6 products built and tested
1 paper published by IEEE
Services
TestProof
Selenium
Playwright
Postman
JMeter
Jira
Git
1
Manual & functional testing
Test plans, test cases and exploratory passes across web platforms. I work from the requirements when they exist and from the product itself when they do not.
Test designRegressionExploratoryJira
2
Automation & API checks
Playwright and Selenium suites for the flows that repeat every sprint, Postman collections for endpoint validation, and JMeter when the real question is how far it scales.
PlaywrightSeleniumPostmanJMeterMySQL
3
IoT & device testing
Testing that does not stop at the browser. Range, reliability, transmission capacity and failure behaviour for LoRa and Arduino systems, in the conditions they are built for.
LoRaArduinoField testing
Evidence driven
I would rather spend ten more minutes narrowing a defect than hand a developer something vague. Steps, expected, actual, evidence. Every report should be actionable without a follow up conversation, because the follow up conversation is where release days go to die.
Steps01
Expected02
Actual03
Evidence04
Open to collaboration with product and development teams
Quality is not something a QA engineer bolts on at the end. I am at my most useful early, in requirement reviews, asking the awkward questions while they are still cheap to answer.
I am a Quality Assurance Engineer at Convergence Lanka, where I joined as
an intern and stayed on full time. My work sits between the requirement document and the
person who will eventually use the thing. I read what the feature promises, poke at what
it delivers, and make the difference impossible to argue with.
Before that I spent six months at the Ministry of Agriculture and Plantation
Industry, building and testing a Conference Hall Management System for their
website. Somewhere in between I finished a BSc (Hons) in Information Technology at SLIIT
and helped put LoRa radios in a forest to catch wildfires early, which taught me that a
test plan written at a desk does not survive contact with real conditions.
I am detail oriented, adaptable, and curious enough about new tools that I am usually the
one who tries them first. What I want out of a release day is simple: nothing surprising,
and nobody having to be a hero about it.
Designed and executed manual test cases across web and mobile applications.
Supported the automation effort, learning and applying Selenium WebDriver and writing my first test scripts.
Ran functional, regression and integration testing to keep quality steady between releases.
Reported and tracked defects through bug tracking tools, working with developers to get them resolved.
Contributed to test planning and documentation, and got hands on with automation frameworks.
Converted into the Associate QA Engineer role.
Manual testingDefect trackingTest cases
Mar 2024 to Sep 2024
Quality Assurance Engineer Intern
Ministry of AgricultureBattaramulla
Wrote test cases for web and mobile systems, then ran manual, custom API, volume and stress testing with JMeter.
Performed functional, regression, integration and UI testing to find defects before they reached users.
Analysed requirements and turned them into test scenarios and cases against the functional spec.
Worked with developers to investigate defects and verify the fixes actually held.
Built JMeter scripts for performance and load scenarios to measure how far the systems would scale.
Kept test cases, results and QA documentation organised for whoever picked the work up next.
JMeterLoad testingPostman
2021 / 2024
BSc (Hons) in Information Technology, specialising in Information Technology
Sri Lanka Institute of Information Technology
Malabe
2019
G.C.E. Advanced Level, Physical Science stream
Sanghamitta Balika Vidyalaya
Galle
2016
G.C.E. Ordinary Level
Sanghamitta Balika Vidyalaya
Galle
On GitHub
The code behind the testing.
Everything below was built and then taken apart again. Testing something you wrote yourself is the fastest way to learn how little the happy path proves.
Two IoT builds where the thing under test was hardware, outdoors, and entirely unwilling to behave the way the desk plan said it would.
Published in IEEE Xplore
FireWatch: wildfire detection and alert system
Nov 2023 to Oct 2024
A team research project building an AI assisted system for early wildfire detection and
response. My side was the IoT layer: real time weather monitoring and emergency
communication for forested areas using LoRa and Arduino,
plus the QA work that validated detection reliability and the fire spread prediction
models. Presented at the International Conference on Advances in Computing and
Technology, paper published in IEEE Xplore.
A wearable that monitors patients with walking disabilities. Pedometer and fall detection
on MPU9250 sensors and an ESP32 C3 at 95% accuracy, with real time alerts over Firebase
and MQTT, and quantised LSTM models in TensorFlow Lite recognising walking patterns at
96% on the device itself. I ran the data validation and the on device performance testing
that proved recognition held up as conditions changed.
ESP32TensorFlow LiteMQTTFirebase
My end goal is simple. Every finding I hand over should end up:
ReproducibleDocumentedFixed
These three words decide how I spend a testing day. If a finding cannot be reproduced on demand it is not ready to be filed. If it is not documented, it will be rediscovered by somebody with less patience and worse timing.
And if it is filed and documented but never fixed, then all I have produced is a very well written list of reasons your users will leave. So I stay on defects until they close, and I re-verify them myself.
Feel free to drop me an email at rashmiupamalika2000@gmail.com if there is something here I have not covered.
Playwright with JavaScript and Selenium WebDriver for UI automation, Postman and JMeter for API and load testing, and SQL against MySQL when I need to confirm the screen and the stored record agree. Defects go into Jira, code goes through Git and GitHub. For device work it is Arduino and LoRa hardware, tested in the field rather than on a bench.
Existing products are usually the more interesting problem. Where there is no documentation I start from the product itself, map what it actually does, and build the test cases from there. That map tends to be useful to the whole team afterwards, not just to me.
Anything that gets run every sprint, is stable enough not to break the test weekly, and would be boring to repeat by hand. Everything else stays manual, because exploratory testing finds the things a script was never told to look for.
A title someone can scan in a stand up, numbered steps, the expected result, the actual result, the environment, and evidence attached. No adjectives, no blame, and nothing that requires a follow up conversation before a developer can start work.
Given the choice, yes. Requirement reviews are where the cheapest defects live. A question asked while a feature is still a paragraph costs minutes. The same question asked after release costs a hotfix and somebody's evening.
My final year research put LoRa radios and Arduino nodes into forested terrain for early wildfire detection. I tested range, reliability, data transmission capacity and speed under the conditions the system was actually built for. It is a different discipline from web testing and it made me much more careful about assumptions.
I am based in Galle and currently working in Battaramulla, so I am comfortable with both. Remote and hybrid QA work is fine as long as there is a real feedback loop with the development team.
Send an email describing what the product does and what worries you about it. If there is a staging link, include it. I will come back with what I would test first and why.
Untested code is quietly spending your users' patience
