A tester asked me an interesting question this morning:
“How can I find old test documentation for a completed feature so I can re-use those tests on a similar new feature?”
The answer is easy. But that’s not what this post is about.
It seems to me, a skilled tester can usually come up with better tests…today, from scratch. Test documentation gets stale fast. These are some reasons I can think of:
- A skilled tester knows more about testing today than they did last month.
- A skilled tester knows more about the product-under-test today than they did last month.
- The product-under-test is different today than it was last month. It might have new code, refactored code, more users, more data, a different reputation, a different platform, a different time of the year, etc.
- The available time to perform tests might be different.
- The test environment might be different.
- The product coder might be different.
- The stakeholders might be different.
- The automated regression check suite may be different.
If we agree with the above, we’ll probably get better testing when we tailor it to today’s context. It’s also way more fun to design new tests and probably quicker (unless we are talking about automation, which I am not).
So I think digging up old test documentation as the basis for determing which tests to run today, might be a wrong reason to dig up old test documentation. A good reason is to answer questions about the testing that was performed last month.
RSS
Also it stops the innovative thinking as well. See the application from another perspective is not healthy. I agree on new test documents in exploratory testing or sessions based testing style.
Agreed ! There are some testers, I'm one, who may feel starved for documentation, and so we may find ourselves making requests from this more out of a place of desperation (i.e. "you've given me nothing to go on, let me at least have SOME benchmark..!" - But what you're saying seems better to me, the sort of thing an assured / not overly worried tester should say, which is that it's all going to be alright, and have faith your ability to test this thing your own way (which, ideally is also the up to date way!) - Thanks as always for your posts, I really enjoy them! Y.
I've found myself in situation when reusing old stuff (including test cases / documentation) took me more time than creating them from scratch.
I won't re-use the test documentation from an old feature, just because is similar to the new feature, mainly just because of 2 reasons:
- test cases that don't represent the new feature can make their way into the new documentation
- creating a new documentation from scratch might result in a better structure
However, I would use an old documentation as "inspiration" for the new one.
Documentation assists in both current and old tests. Sometimes knowing what happened earlier allows the user to better understand how the current test and documentaction should work with the old
100% agree ith your ideas. Nowadays everyone is expecting to release their product faster than their competitor. so it makes sense to work on real dynamic testing and save time on static testing.
My 2 cents... We've been burned too many times by not having accessible, centralized test cases. We have a lot of different paths in our software (even though what we do doesn't seem that complex). I think its partly a function of time. We've seen instances where a problem crops up with something that we implemented 6 months or a year ago, but nobody (coder, BA, QA) seems to remember just how it was supposed to work, and the story is clearly not adequate to refresh our knowledge.
We've started (in 2016) working with a centralized repository for test cases, and it is much easier to look back.
I agree that we shouldn't rely solely on old test cases for new testing efforts, but for regression testing, it seems like a very viable strategy.