Michal Sierzputowski Performance Tests TGT 22

1. Performance Testing
#ShareTheFail
Trójmiejska Grupa Testerska
Michał Sierzputowski
Gdańsk, 12.12.2018

2. Fail #1: Leave Performance Testing until the last minute
https://i.ytimg.com/vi/hEmrapoJ498/maxresdefault.jpg

3. Solutions
● No User Stories?
Talk with business people on the performance impact on your system
and how users really intend to use the application
● No experience in Performance Testing?
Start with record and playback tools
● Not enough time, other priorities ?
Create simple scenario – use 80⁄20 rule - Pareto principle, to uncover
low hanging fruits

4. Fail #2: Don’t expect unexpected
https://commons.wikimedia.org/wiki/File:Black_Swan_bg.jpg

5. Solution: Exploratory Performance Testing
Virtual users
Test time Test time
Virtual users
Virtual users
Test time
Virtual users
Test time
Load test
Soak test
Stress test
Peak test
~1h ~24 h

6. Fail #3: Rely on your load testing tool’s results only
https://photoseek.photoshelter.com/image/I0000taTnXMWCcDk

7. Solutions
● Setup platform for
analytics and monitoring
● Engage whole team
https://pbs.twimg.com/media/CkwxzSIWEAE1q_r.png

8. Fail #4: Don’t verify where you are
https://fineartamerica.com/featured/ever-feel-like-youre-in-the-wrong-place-tom-schwabel.html

9. Solution
● Assert on the response content not only HTTP code or URL

10. Fail #5: Fire your requests as fast as you can
http://comicsalliance.com/comicsalliance-reviews-the-mask-1994-part-two/

11. https://msdn.microsoft.com/en-us/library/bb924367.aspx
Actual Distribution of User Activities Over TimeUSERS
T I M E

12. Solution: Model real usage of your applicationUSERS
T I M E

13. Solution: Model real usage of your applicationUSERS
T I M E
Server perspective of User Activities

14. Solution: Model real usage of your applicationUSERS
T I M E
Server perspective of User Activities

15. Solution: Model real usage of your application
Server perspective of User Activities
USERS
T I M E
VS.

16. Fail #6: Write
performance test scripts
as they were recorded
by a tool

17. Solution: Apply good software engineering practices
● Write Clean Code
● Keep it DRY
● Keep it readable
● Use appropriate business transaction names
● Setup common standards

18. Fail #7: Don’t verify your tests – just run them as soon
as they are ’finished’
https://commons.wikimedia.org/wiki/File:JetBlue292Landing.jpg

19. Solutions
● Verify your test data.
E.g. Run a quick login script to see if all user ID’s are still valid.
● If single user script works verify it in concurrent test
● Verify that all expected data were processed /created / deleted
● Run smoke test before executing full test

20. Fail #8: Make business people happy first
http://www.cah.utexas.edu/db/dmr/image_lg/di_05812.jpg

21. Solutions
● Execute a slow ramping methodical test to understand the current scalability
● Baseline with a single user to get an idea of the minimum achievable
response time.

22. Fail #1: Leave Performance Testing until the last minute
Fail #2: Don’t expect unexpected
Fail #3: Rely on your load testing tool results only
Fail #4: Don’t verify where you are
Fail #5: Fire your requests as fast as you can
Fail #6: Write performance test scripts as they were recorded by a tool
Fail #7: Don’t verify your tests – just run them as soon as they are ’finished’
Fail #8: Make business people happy first
#ShareTheFail

23. Questions ?
Michał Sierzputowski

24. THANK YOU
Michał Sierzputowski