Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Hrm . . . actually, I could give a list of ideas for reduction of a cookie recipe (or an issue in a cookie recipe), if I knew the domain well enough. Someone does it right here: allrecipes.com/HowTo/perfect-cookies/Detail.aspx This is the cookie equivalent of what I'm looking for in bug reduction.
+1 - your last paragraph is exactly the kind of thing I'm looking for. My own "product / feature" is huge, encompassing multiple services, applications, and web pages (small company, each employee has a large area to cover), so almost every tip will apply to one product or another.
Good question :) I want to point out that you haven't reaped the full benefit of your automated tests yet. They will continue to provide value for future iterations as well, as regression tests.
SharePoint has the advantage of being liked by non-techies. I like the ability to link as I use the terms in a wiki, but my audience is almost always technical, and they like wikis also.
You misunderstand the purpose of the checklist. The goal is to convey experience with testing. Newer testers are more likely to think about functional issues when reducing a bug (in fact, you do precisely this!). More experienced testers know that these bugs are fairly easy, but what about intermittent bugs where you can follow the exact same steps and reproduce it once, but not the next time? Memory, CPU, race conditions, timeouts, etc. can all play into these bugs. How do you reduce them? That's where a list of steps / tricks comes in handy.
I disagree. The problem isn't getting the respect of the business folk, it's finding good technical companies that recognize that software is a unique business that traditional business-folk just don't understand. The most skilled members of the testing community tend to shun standards like these, instead choosing to work at companies that respect their talents. These standards have been around for a while, and the best companies generally ignore them.
A wiki can be a useful place to define terms. If the company uses them differently than the general test community, you can give the company definition and then include at the bottom a link to the more common definition outside of the company.
As I understand it, the concern about x vs y is that people are likely to fall into camps if the question is wide open, plus the question of simply x vs y doesn't necessarily solve a real problem. This question has a lot of other details that affect whether x or y is more appropriate, and seems open to suggestions of z or w, plus is very clearly a real problem for which the OP needs a solution. I think those are key factors.
Please edit this with the duplicate revisions. I think this is very helpful when framed as communicating the role of the tester using humor. I know I could use good comics to post in my cubicle to reduce dev / test tension and help explain some of the more, ah, "challenging" tester behaviors.
"First run" performance might be something you want to check. So, these can both be performance tests. I'd say don't load for most performance tests, for consistency; but be aware that you are missing some key scenarios, and decide if you need to make first run performance tests. Keep in mind that first run is your end user's first impression. I've also found that performance testing is often where the most interesting concurrency issues are discovered on large teams.
