Don’t do this ✋🏻
In this second episode i will try to mention some other practices i have noticed or did it myself in the past , that is not recommended.
1) Don’t assume requirements , get a confirmation first
It happens sometimes that we don’t have a strict requirements and at the same time we need to have something , any output that can give us a hint about where we are right now.
Don’t assume requirements yourself , ask for help and discuss the requirements that you can think of with the dev team , product owners , architects and management if you can , you need confirmation that what you think of is aligned with what they are expecting.
I am talking here specifically about things like response time , users and scenarios or flows.
2) Don’t execute a performance test without think time
Although in some cases the purpose of testing is to put the system in pressure to see if it can handles the incoming requests or not , but not having think time will make most of the results a non realistic results , as in any system there is some sort of delay that simulate the end user behavior.
Using think times in a load test can be useful in creating more accurate load simulations.
3) Always add validations and verifications in your script
Although the server response should be enough that we you receive response code 200 , everything should be working fine but unfortunately this is not always true , that’s why you need to add verifications / assertions to your script to make sure that it is working as it suppose to.
It is frustrating when you complete a set of runs and realize that you were having errors in the response and you weren’t aware of.
That’s for today , hope you find it useful 🙂
Please share your tips, experience, comments, and questions for further enriching this topic of discussion.
Leave a Reply