- This topic has 10 replies, 10 voices, and was last updated 7 years, 3 months ago by
.
-
Posts
-
Have many come across this before. Some testers I have met have mentioned it to me that there are occasions where they might start on a project but are expected to come up requirements based on previous experience, best practise or working with the product.
Has this happened to you and if so, what has been your general approach to this projects?
How do you decide on the project requirements?Well, yes it has happened to me – and it will no doubt happen again.
For a lot of software the requirements are at least partly self-evident, i.e. calendars or to-do lists have a fairly standard and limited set of requirements.
The non-standard requirements can often be discovered by looking at options and preferences where you get a good idea of what the application is able of doing, i.e. should the calendar application be able to support networked calendars.
For systems intended to succeed an older system a lot of the requirements can be learned from observing the system to be succeeded.
For some far more complex systems like banking systems you can get a very good idea of the requirements for an application by knowing its intended use and having a fair amount of domain knowledge.
And lastly when working in an Agile / Scrum team requirements are constantly changing so they are not at all clear at the start of the project – and sometimes they even change during a sprint because developers discover something good or bad that changes everything.This is not to say that you don’t need requirements but in general I don’t need fixed requirements when starting on a project.
When I get in a situation that I really need them I can always go to the product owner and let her/him make a decision.We have recently had a project where there was no testing resource to hand for the last few months, so now before release we were meant to test the piece of software.
Again there was the question of requirements. I solved the issue by learning from the people involved what they wanted from the piece of software. Why were we even asked to code it? How will it improve the user experience? Does it affect internal systems at all?
I then structured my code based on the requirements deemed to be of the most value.I agree with Kasper though. In agile requirements constantly evolve and change and here it is important to re-evaluate on a regular basis.
Generally if you are lucky enough to have a legacy product to learn from then this can also help define the new requriments.I hope I didn’t waffle to much, but I think as much as we can test without requirements and then feed back information about the product to the team, it is good to get an idea of why the software is of value to someone.
There are requirements, of course. They just are not documented. In such situations, tests in fact can be the closest approximation to the requirements; but be very clear that tests are tests and not requirements, regardless what TDD and ATDD think. Yes, testers may have to apply various discovery techniques to make their best guess at what tests should be.
The bigger problem is that many, if not most, projects that do have documented “requirements” actually still don’t have adequately-defined REAL, business requirements deliverable whats that provide value when satisfied by some product/system/software how. Rather, most “requirements” are high-level design of a presumed product/system/software which will provide value if and only if it satisfies the REAL business requirements. Testing that the delivered product conforms to its design provides only limited benefit by demonstrating that the product was built right but says nothing about whether the right product was built. Inferring requirements from the code is the height of uselessness.
Robin F. Goldsmith, JD advises and trains business and systems professional on risk-based Proactive Software Quality Ass
Excellent point Robin.
There are requirements, they’re just not documented, and when they are the documentation is inaccurate or incomplete. And of course, the customer most likely doesn’t know what their real requirements are — they only know something’s not right when they see it.
I call this “defect driven design”
I am into freelance testing and this is very common in freelancing. The requirements are not documented. Sometimes a quick walk-through of the application is given and at other times just the URL or exe to be tested. So, in such cases if you feel something does not seem to be right either you ask, raise it as a defect or put it forth as a suggestion.
Yes, it could happens. A combination of exploratory testing and pair testing (to combine different expertise) would be good to start testing a development with no requirements in place. The exploratory testing will help testers to understand the development and contribute to the creation of the official requirement along with the business team.
This scenario could happens when a product is developed by a partner company and the testers and even local developers do not know well the product.
Regards.
yup, it happens when projects are especially light on doco. I usually test based on experience, exploratory and interview based. Of course, google is treasure trove of info and resource 🙂 happy testing
Requirements are inevitable and testing without Requirements is quite hard because we don’t know what’s expected from the system.
In this case we should ask from domain experts (if available) and try to understand the flow of the system and work with whatever little documentation you can get It can be a basic simple backlog (in agile projects), a help file etc.
- You must be logged in to reply to this topic.