This is the fifth installment in a multi-part series to address the basics of performance testing applications. In this segment, we introduce the concept of creating Business Process Profiles and Server Configuration Profiles to help organize and prioritize business processes used for automation, as well as documenting the server resources for the system under test.
Undoubtedly, some of you have made the determination that your team is not Agile, but is indeed Fragile. Some of you knew it before you even read any of the blog, but now are even more convinced. But what are you willing to do about it? Are you ready to break down that façade and begin the journey to changing from Fragile to Agile? If your answer to this question is yes, then I recommend the following strategies that can help you achieve that goal. This is not an exhaustive list that when followed will ensure with absolute certainty that you will transform your organization, but these strategies have been proven to help begin that transformation.
In the traditional development space we are all very familiar with the testing tools that are available. We know about industry leaders such as HP Quality Center, QuickTest Professional and Performance Center. We understand the value they add to large projects and how they are essential to ensuring that the testing process is well managed and delivered. But what about Agile? Do these same tools have a place in the agile framework? Does the speed of Agile even allow for the use of testing tools? The answer to all of these questions is a resounding YES!
Often times teams make the argument that Agile means that there is no longer a need for “independent” teams of testers that verify that the solution was built correctly according to the requirement specifications. They argue that this is now the role of the “super developer”, and the business representative, who are both embedded into the team. After all, the business knows what they wanted in the first place. Agile in and of itself doesn’t change any of “Brian’s basic laws of software development”
If you were to survey a group of very frustrated testers about why they have problems with their Agile teams, you would find that in almost all cases they get frustrated trying to get any documentation that helps them identify what to test. Every time they request even minimal documentation, the development team pushes back and says that documentation isn’t needed because Agile eliminates the need to document. After all, Agile promotes “Individuals and interactions over processes and tools”. They will tell the tester to just talk to the developer about what they are building and it will become obvious what the testers should be testing.
The last Agile principle is all about retrospectives. This is one area where a lot of teams have dropped the ball. They don’t take the time to do retrospectives because people don’t understand the value they bring. They are perceived as a waste of time that could be spent on the next development sprint. What they fail to realize is that on a long marathon, it is the small corrections in the sprint execution that make the difference between success and failure. True Agile teams take retrospectives seriously, and each and every team member is laser focused on improving sprint over sprint.
This is the 4th installment in a multi-part series to address the basics of performance testing applications. We outline a case study about determining the peak load to help better understand the performance testing process.
Categories: Performance Testing and Automation, Quality Assurance
Tags: Best Practices, duration testing, load testing, LoadRunner, Performance Center, performance testing, Performance Testing and Automation, Quality Assurance Tags: Component Testing, software testing, stress test
Agile principle eleven deals with the team itself. This principle focuses on the enablement of the team to leverage their unique position as the closest people to the problem manage the work. It also enables the team to safely take risks. The team is typically creating new solutions, and doing it in a rapid fashion. Agile promotes the team trying new things without worrying about being chastised for wasting project time. Teams are encouraged to learn from their mistakes to improve future sprints, and improve the overall delivery. One of the biggest indicators that a team might be Fragile is that leadership still insists on reviewing and approving the project plans, and changing direction. This is NOT a characteristic of an Agile team. This is the characteristic of a leadership team that has not empowered the team to be successful.
Out of the box, QTP provides limited VBScript debugging capabilities. Learn how to enable enhanced debugging features by registering a new Process Debug Manager (PDM.dll).
The tenth Agile principle focuses on keeping the solution as simple as possible while maximizing value and quality. Agile processes focus on finding the simplest way possible of solving a business problem with quality, not finding the fastest way to code the solution. Sprints are kept as simple as possible to ensure that all work gets prioritized by using the backlog as the gatekeeper. In the Fragile environment workload constantly changes in an effort to keep up with changing priorities and constant feature churn.