Many times when performance testing, I'll manually calibrate my performance test script by loading the page manually and comparing those load times with those generated from my test tool. Doing this with a load of one user allows me to get an idea of how much my tool is skewing the numbers. Often, I find the tool is just a tad bit worse in terms of response times. If it's too far off, that normally tells me something is wrong.
Recently Microsoft released Spec Explorer 2010. Spec Explorer is a tool for model-based testing. From the website:
The team that developed the tool also maintains a blog worth checking out.
Spec Explorer 2010 is a tool that extends Visual Studio for modeling software behavior, analyzing that behavior by graphical visualization, model checking; and generating standalone test code from models. Behavior is modeled in two ways: by writing rule machines in C# (with dynamic data-defined state spaces) and by defining scenarios as action patterns in a regular-expression style. One of Spec Explorer’s major features is the ability to compose models written in these two styles. This technique enables users to slice out test cases from large state machines by defining relevant scenarios, thus tackling the notorious state-space explosion problem pervasive in model-based testing. Spec Explorer also supports combinatorial interaction testing with a rich set of features.
The team that developed the tool also maintains a blog worth checking out.
If your team already does some pair testing, take a look at promiscuous pairing.
Try 60 to 90 minute sessions where you alternate partners each session.
"Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels — and allow someone else to take over for his weaknesses."
Try 60 to 90 minute sessions where you alternate partners each session.
As testers, we get a lot of "FYI" meeting invites. When you find that you're getting invited to meetings and you're not sure why you need to be there, take a second and reply to the person who scheduled the meeting and ask "What's my role in the meeting?" This allows you to better know what's expected, and based on their response it also creates an opportunity for you to express that you might have higher priority work to do or to ask if you can dial-in instead of attending in person.
At last night's IWST on time management, Chris Wingate shared a technique he uses when trying to coordinate performance testing for projects. Chris schedules two 30 minute meetings each week. Instead of constantly following up with people to see where they are and to see if he has everything he needs to proceed, he focuses on his part of the project and lets the project manager get and manage other people's commitments. This allows him to work several projects at the same time, because in each of them he's focusing only on his piece of the work and not trying to duplicate the effort of the PM.