Vishwa Ranjan

• Jun 27th, 2007

 

I belive it should be consider as a BUG, because any thing which is not mentioned as requriement can be consider as BUG rather it is good or bad. We can suggest to add that functionality in the next built but before that we has to consider that as a BUG only.

I look forward to your feedback.

Thanks
Vishwa Ranjan

karunakaran.S

• Sep 24th, 2007

 

Yes, i am 100% sure that its a bug and not an issue also.
But i think there is nothing affects Test plan with effect to this bug.

sandeep kumar

• Nov 23rd, 2007

 

I Agree what they are saying but it depends on organisation have different rules
some small company dont provide document and they inform what this project consists in that condition you have to study the project and assume yourself this functionality should work like this. This Type of testing is called Adhoc testing without any plan and test cases

cjayesh123

 Profile Answers by cjayesh123 

• Mar 18th, 2008

 

Everybody I respect your sentiments towards Testplan, But it cannot be treated as a Bug or an Issue but it needs to be treated as a Change Request and this will be marked in the RTT (requirement traceability Metrics) as CR and will be released in next build or version, if it is approved by Customer for additional cost if it is major functionality or approved by the delivery PM if it can be given free of cost as the case may be. Onthing more Testplan is a dynamic document which can be changed over a period of time by having change control mechanizm. Based on the same Test Schedule is prepared.

saransh.kanaujia

 Profile Answers by saransh.kanaujia 

• Mar 22nd, 2008

 

A test plan is possible to write on the bases of srs. If srs is also not availble we have option to first test the project and then write test plan according to that. I thing it's a good practice to deal with project like this.

vk1978

 Profile Answers by vk1978 Questions by vk1978

• Apr 15th, 2009

 

The availability of functionality in the application that is not mentioned in the requirements, first such things will be raised in the team meetings and communicate the same with development team and also will raise that issue as a defect whether that functionality is impacting on regular functionality or not.

rahulskin

 Profile Answers by rahulskin 

• Sep 18th, 2009

 

It is Requirement Specification defect. 
After updating the Requirement Specification, the testing plan can be updated based on the change in the RS.

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Nov 14th, 2009

 

When an application has functionality that is not covered in the requirements, the Business Analyst (BA) needs to be notified and either the BA or Project Manager (PM) needs to submit a Change Request.  Afterward, this new functionality needs to be documented in the Business Requirements Documentation (BRD).  Once this has occurred, then the tester creates test cases based on the requirement(s) and maps the requirements to the test cases through the quality management tool (also known as a defect management tool).  When the test cases are mapped to requirements, this new functionality can be also called out in the project's Test Plan. 

srinivasulub1981

 Profile Answers by srinivasulub1981 Questions by srinivasulub1981

• Nov 28th, 2009

 

HI

  Then we need to plan for Adhoc /Exploratary tesing in the plan

CNU

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Dec 6th, 2009

 

When I first read the question, I didn't fully understand the issue, but now that I have reread it, it becomes quite clear that this scenario would require an immediate revision to the Test Plan.  

My actions will depend on where in the Testing Phase of the Software Development Life Cycle we are at.   For example, this issue becomes more urgent the closer we get to test execution.  If we are currently in the midst of a test run, this would qualify as a Test Lead's nightmare!

Nevertheless, this is how I would handle the situation:
1) I would personally devote as much time as needed to learn as much about the new functionality as possible and I will do this as quickly as possible.
2) I would make a quick estimation on the additional test resources and time required to recover from this oversight. 
3) I would discuss this issue with the Test Manager (unless I'm the Test Manager) and find out whether we have additional test resources to devote to the learning, planning and test case execution of this functionality.
4) I would discuss the requirement gap with the Business Analyst (BA) and Project Manager (PM) and let them know that the test schedule estimation may need to be revised to accommodate this new functionality. 
5) I would expect the BA to add requirements corresponding to this functionality in the Business Requirements Document (BRD). 
6) I would revise the Test Plan to include the new functionality in the "Features to be Tested" or "In Scope" section.
7) I would add an additional folder for this functionality in the test suite.
8) I would author test cases for the new functionality.
9) I would map the new test cases to the new requirement(s).
10) I would prioritize the new test cases
11) I would conduct a peer review to verify clarity, accuracy, and completeness of test cases.
12) If the new functionality requires test tools or test environment considerations, I will ensure these things have been addressed and are ready for test.

At this point, we should be in a good position to begin test case execution.  If we have additional test resources to apply to this new functionality, we may not need to change the test schedule associated with future test cycles.