Do you test performance when your team develops new feature? Why not? Performance testing is often found as difficult and omitted by developers.

I’d like to take you on a pragmatic trip through web application performance testing. We’ll start with low-effort activities taking rough assumptions to get immediate results. Then we’ll learn what drawbacks and trade-offs we’ve made and try to improve accuracy of our measurements.

We’ll exercise various scenarios so that you can grasp broad, holistic approach to the topic:

• Performance checks during exploratory testing (e.g. Fiddler, Charles proxy, YSlow, Chrome dev tools)
• Load generation (e.g. JMeter, Gatling)
• Application Performance Management solutions (e.g. New Relic)
• Utilising staging/dogfooding/demo environments to learn about performance
• Monitoring tools (e.g. ELK, Splunk, Grafana, Graphite)
• Data volume testing
• Using Selenium to get client side performance metrics

Given 3 hours I’ll not go into details of above aspects. I’ll cut theory to bare minimum. I’ll concentrate on specific, hands-on examples showing value of given approach. After each example you’ll be tasked to execute similar exercise during our workshop.

Take-aways:

• Convince that performance testing is not a secret knowledge for chosen ones.
• Learn variety of attempts to performance testing.
• Learn portfolio of tools that will help you test performance.

Przed warsztatem

Przed warsztatem warto jest pobrać repo https://github.com/konradmuh/kick-start-performance i spojrzeć w nagłówek ““Prerequisites”” z README.md

Zajęte miejsca: 0 / 16