Someone recently asked me, “How do you implement load testing so early in the development process”? I thought about the question for a second before coming up with the following answer:1) Don’t just say you’re going to load test, do it – If you’re a team lead, manager, or qa engineer it’s easy to make excuses why you can’t start testing early in the development process. But there are always some low hanging opportunities even if you don’t have the perfect person to execute them, the most appropriate tool set, or even reasonable areas of an application to test. Ingraining load testing into the development process and making it a discipline needs to be the first objective.2) Identify objectives and test criteria – Early test criteria should focus on the testing methodology itself and simple validation. See my previous post on why The First Load Test Always Fails. But as you mature your process, engage stakeholders to identify performance goals (response time under load), and volume (peak traffic levels).

3) Identify your resources – If you’re serious about load testing, you have to invest in the right people and tools. It takes a comprehensive set of skills to perform load tests properly. I’ll post some criteria in a future post.

4) Make the QA Engineer part of the team – A co-located team is a key attribute (requirement!) of making agile work, so make sure the QA Engineer has a seat with the team. This promotes teamwork, collaboration, and enables the engineer to pick up technical details that enable him/her to craft better tests.

5) Implement load testing as an agile process – The hard part of implementing load testing during a traditional development cycle is that it’s difficult for the QA Engineer to truly know what areas of an application are done and ready for testing. That’s not the case in agile since the stories are identified, the time line fixed, and the acceptance tests itemized. The QA Engineer knows what’s being developed, its completion date, and its scope and can build tests in parallel to the development cycle. The goal should be to implement these tests as part of the acceptance tests (ideal), or in a staging cycle when a release is going though testing and regression.

6) Today’s performance issues become tomorrow’s stories – The load testing life cycle is like peeling an onion; once you find today’s issues and address them (the outer layer of the onion), your next tests will identify the next set of issues and performance optimization opportunities (the next layer…). This life cycle is highly complimentary to the agile life cycle. As issues and opportunities are identified via load testing, the resolutions can be documented as stories and prioritized in a future sprint/iteration.