How to keep track of the features in a website for impact analysis?

Question

I have been working for an ecommerce client for the last 6 years as manual and automation QA engineering. New features gets applied to our site once in 2 weeks. Whenever a redesign project comes up, like say product page redesign - we keep forgetting to handle all the numerous features which were implemented in last few years. People who implemented it move out of the team often and its forgotten after sometimes. Its not the major features, but minor ones that are having this issue.

I was searching for ideas on how to keep track of all the features in the website. Ideally, when a new requirement comes we should be able to easily identify the impact of the new project on existing ones using this solution

Answer 1

What you need is to improve your Requirements Engineering processes. There are commercial tools that help in this area (I have worked with Doors some years ago), but I don't know of any open-source alternative I could recommend.

The problem is that these tools and processes are very "heavy weight", and in my opinion, achieving requirements traceability down to code and backwards is very expensive¹ and probably not worthy for software not subjected to any kind of standards compliance (for instance, safety requirements like DO-178B).

---

Notes

¹ Requirements traceability should though be feasible using some code generation tools, but I don't have experience in this area, and I'm afraid it's also out of the scope of your question.

Answer 2

"we keep forgetting to handle all the numerous features which were implemented in last few years"

If things are being forgotten on a regular basis, this isn't a tool problem - it's a process problem. Your process seemingly doesn't require that these things are tracked in an accessible place, and that the feature list be kept up-to-date.

We use SharePoint to hold our features/requirements. When it is maintained well, we can use it for impact analysis. When it isn't maintained, we cannot.

Answer 3

I approach that problem by maintaining written test cases in a wiki. Each test case is a declarative statement. (I have worked places where test cases were documented in step-by-step detail, but I found it was too hard to maintain the details when features changed, as they often did.) If you search SQA or Google, you will find other structures for written test cases. With some thought and experimentation, you can find one that works for your own organization.

I was the only tester in my little company for two or three years. When our second tester joined the team, the written test cases allowed her to learn the product more easily than she otherwise would.

I have had less success documenting test cases in such a way that it is easy to map a new requirement to the impacted test cases. You can get part of the way there by tagging a test case (or a page of test cases) with the relevant product components, but picking an appropriate granularity of tag -- neither too high-level or too low-level -- is easier said than done.

Answer 4

There are plenty of ways to keep track of the requirements.The very important thing to be considered is to keep track of requirements and changes from the Inception of thoughts/Requirement analysis, without which it might become a costly affair.

Requirement Analysis Aiding Tools-

1. An Excel sheet could sometimes be the simplest way to keep track of requirements and impact analysis.
2. I've used HP Quality center, Which was really a very good ALM tool for Requirement trace-ability and Impact Analysis.
3. I've not used Doors but that could be another good option.

Process:

1. Categorize the Requirements/Use Cases/Stories.
2. For Each Category Draft the requirements relating the list of dependencies.
3. Create a Matrix with the Requirements and Dependencies as Base.
4. The Impact Analysis should consider all the dependencies.
5. So whenever there is a change in the requirement around a particular categorized feature all the dependencies must be considered and all related requirements/Stories/use cases must be handled.

Since you've mentioned changes happen every 2 weeks, one more way of avoiding unexpected breaks and miss in any dependent features would be following a Continuous Integration Test Driven Development, where any breaks and dependent issues will be identified when you are committing the changes to the build.

Even after a perfect impact analysis, you could still see issues but keeping that under control should be the goal.