Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I have been trying to figure out ways to effectively do performance reviews before an install happens for all releases done by our team. Do you usually make this a part of code review process or do you handle it as a separate review task?
FYI - we do not have a dedicated performance testing team. It is up to the developers to make sure the app performs well. The apps I am referring to are web applications.
I think it's a great idea to make it part of your daily automated testing. I wish we had done that. For example, starting up the app should take some length of time in some machine, like say 30 seconds, so if it takes more than 45 that should be considered a bug.
Performance problems creep in during development, so they should be dealt with along the way, not at the end. They should be considered as qualitative problems to be debugged, not quantitative ones to be shaved away. My primary method of finding them is random-pausing.
Performance review at the end probably will not work. It is something that you have to think about at the beginning of your project and make it part of your design. You can have a performance test team verify that it works as intended, but even doing that is late in the cycle and expensive. We had a performance testing team at one point in my last project. It was great that they found issues, but since it was so late it was basically impossible to make their results matter. It usually meant reopening the design and fixing it with another project.
Bottom line, you have to have performance targets/ideas in the design before you write the code. We added sections to specification documents that required you to think about performance while designing the project.
