How would a test plan be constructed that is for exploratory testing? I would assume it is different from a traditional test plan? Would we use concepts such as entry/exit criteria for test? I would never say No to a build to test. Skipping entry/exit criteria. I guess it also has to do with the […]
You are on a quite large company where there are several QA divisions, several layers of management, several listeners to each step of the development process. It is the final weeks of the release. You are about to enter a bug which seem serious but you are not sure. You can take at least two paths […]
This post was triggered by blog post Resolved as Not Repro – http://thetesteye.com/blog/2009/06/resolved-as-not-repro/ I believe that bug systems too often are used with onlý a this-project-right-now approach, where you care most about just getting all items dealt with. This is perfectly fine for one-off type of projects, but does not work fully for software where the […]
Lets say that you have a bug system; and for each bug you have the two fields “State” and “Resolution” where the following values are valid: State: New, Assigned, Resolved, Closed. Resolution: Fixed, Invalid, Won’t fix, Duplicate, Not Repro. Further, you have a field where a product version number should be entered; i.e., the earliest […]
How is information handled around the decisions for the product release? There are many different situations around this, the following is what I’ve experienced and my tips and tricks. In many cases there is no information available or rather it is not presented to the decision makers. It also common that the information is not […]
New RSS: http://thetesteye.com/blog/feed/ The Swedish software testing blog “thoughts from the test eye” changes blog software and will from now on run on WordPress. The old software didn’t have good enough RSS support, wasn’t appealing to the eye, and had some smaller usability issues that was becoming too annoying. The start page will still be […]
Sometimes it is said that each test case must have an expected result, or even worse, that each step of a test case must have an expected result. This is the extreme of scripted testing that I dislike for two reasons: * It takes a lot of time to write and follow detailed test cases; […]
”Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team’s established development process and policies.”, see http://trac.edgewall.org/ […]
The short answer goes: No, of course you can’t! Once upon a time, I got the possibility to read a test strategy document written by a business colleague of mine. The strategy was a 47 pages document that tried to cover all aspects of testing that I guess would apply to all projects; because in […]
I seldom see discussion about our status reports. I refer to the reports that we write for the release, iteration, build and so on. There are several templates and standards out on the internet but I have not read any ground breaking updates in that area for a long time. Many might see the status […]