Exploring Rypple’s Project Environment using Heuristic Test Strategy Model
You’ll notice in my email exchanges with Rypple I’m digging out more project related information without even trying. The heuristic test strategy model for the project environment has another mnemonic – CIDTESTD.
An easy way to remember this is to remember the phrase “Kid tested – mother approved.” or in this case “CIDTESTD – mother approved”
It stands for
- Customers
- Information
- Developer Relations
- Test Team
- Environment and Tools
- Schedule
- Test Items
- Deliverables
So what are some of the nuggest I have discovered about the project from my interactions with Rypple?
Customers
- I’ve discovered the product is in a private beta that you sign up for and someone at Rypple has to manually approve. This was a point of contention for one person who left a comment on a blog. Maybe it’s not clear enough to them that it’s a private beta?
- I have figured out that the target audience is people who are in the position to give and receive feedback. There seems to be a lot of talk about Gen-Y and gap between them and “older generation”
Information
- I’ve learned that they use an Agile process of some sort but subscribe to a particular flavor of scrum/agile implementation
- I will need to dig in deeper into the history of the product. I’d also look into any 3rd party software they are using. I’d review the bug lists for those products and see if any of the issues can affect the product.
Developer Relations
- It appears as though most developers are friendly and open to feedback if my interactions with Tiho are any indication. I’ve been able to get good, quick feedback from him consistently.
- Security is an area where I pick up on something important
Test Team
- I don’t know anyone in particular on the test team right now but I do know they have test harnesses.
- I am starting to realize that I don’t have any expertise in web security testing. There are a couple of approaches to fixing that 1) Read up and practise testing for security related issues 2) Call on people I know to help guide me 3) Hire someone else to do the security testing.
Equipment and Tools
- It sounds like they can set up a development environment right on their own desktop boxes.
- They have an offsite hosting facility.
- I’m creating matrices and checklists for myself as I go
- I really need to get information on how the developers debug problems and the tools they use.
- They support all major browsers and versions
- They “have plenty more to come when it comes to integrating with other online services”. Got some stuff find out there.
Schedule
- My arbitrary schedule is to be done my test plan creation, risk and coverage matrices and charter list and top 10 issues by Tuesday March 24th, 2009.
- There is a test harness that helps with the regression testing of the weekly code drop
Test Items
- For the scope of test items I’m working that out with Rypple as I work through this process.
- The product is available.
- I am unsure how volatile it is.
- I don’t have any access to the internal workings to know what has a been added lately.
- I can see from the public blog that they just added a connector to facebook.
- The product appears to be reliable enough for me to effectively test it.
- They are doing weekly drops of the code so volatility doesn’t seem like that much of a concern. I guess it depends on whether I’m testing in the context of scrum or not.
Deliverables
- I’m making written reports of my whole process as I go. If I were working for Rypple I would probably not make all this information available in written format. Most of it would be verbal, brainstorming, modeling etc.
- If I worked for Rypple I would see that part of my deliverables were given to other teams – mainly the list top 10 issues a critic might say needs to be given to support and services.
Discovering these things about the project environment and then probing them more might lead me to better information and charters later on.
