STAKE HOLDER DISCUSSION

1)      This is an important step in requirement study. Make notes of all the points that needs to be confirmed or clarified or suggested regarding any of the above mentioned steps.

2)      Discuss it with all the internal stake holders of the application which includes

1. Other members of test team
2. Test Team Manager
3. Product Manager for the specified application
4. Development team members etc.

3)      Any requirement clarifications pending after this discussion and any understanding reached should be noted and recorded and notified to all stake holders via email

4)      External stake holder interaction (like customer interaction) may be initiated via business team after this with proper escalation.

SOFTWARE REQUIREMENT SPECIFICATION (SRS) VERIFICATION

1)      SRS should have the descriptive details on all the requirements – existing and new for the release.

1. Should include details on functional, non functional, performance and design requirements
2. Details of interfaces and GUI specifications should be present.
3. For each functional requirement it should clearly specify:

• What all has to happen on doing a particular action on the system?
• Where all it should happen?
• When it has to happen?
• What all should not happen?

1. If any of these is not specified , identify it and note for discussion.

2)      Proper version history for the various features should be mentioned.

3)      All the new features should be elaborately explained in the SRS.

4)      It should mention the operating environment (Software and Hardware) recommended for proper functioning of the application.

1. Should include OS, additional (3^rd party) software or packages (with version) required for the application.
2. Recommended values of system memory, RAM, processor speed, server/Desktop usability etc should be mentioned.

5)      Any constraints on the design, H/w or S/W requirements, Standard compliance, etc  should be mentioned in SRS

6)      Any testability limitations should be clearly specified

7)      All assumptions based on which the application is developed should be listed

8)      Interface diagrams, Call flows or flow charts depicted should be cross checked with the understanding obtained.

9)      SRS should have reference for all records like CDR parameter details, Configuration file parameters details and other operation steps.

10)   Ensure that all the requirements are properly reviewed and signed off by respective stake holders/stake holder representatives.

INSTALLATION NOTES VERIFICATION

1)      Installation Notes should describe step by step procedure for

1. Installing a new instance of application.
2. Upgrading an existing instance to latest version of application.
3. Back Up and Roll back of the application before and after installation of this release.
4. DB Package installation/Rollback  if any.

2)      It should have exact information about the various files present in this release bundle.

1. Size and name of every file should be mentioned.
2. Checksums of exe files should be mentioned.
3. Verify these data with the files available in VSS.

3)      Dependent versions of interfacing applications should be accurately specified.

1. Verify this data with the stake holders of the dependent products and get feedback.
2. Escalate in case if any of the dependent products specified is not available or outdated

4)      Any new configuration parameter introduced should be specified with its purpose and various values possible for them.

ROOT CAUSE ANALYSIS FORM VERIFICATION

1)      This document should have proper explanation about the defect identified in site. It should explicitly mention how the defect is reproducible.

2)      This document should clearly mention why the defect is happening.

3)      It should also mention how or in which phase of the SDLC the defect was missed.

4)      There should be clear information on steps to avoid these kind of defect leakage to site.

RCA should mention the fix/action taken to fix this defect reported from site.

APPROACH NOTES VERIFICATION

1)      Approach notes should mention all main possibilities of implementation of any new feature/enhancement.

2)      It should mention the method selected from among these possibilities.

3)      There should be a clear reason for why this approach was selected from among others.

4)      Note down any other (better)  approach of implementation identified and discuss  with stake holders.

1. Note the advantages and disadvantages of this possibility (if identified).
2. Be clear on why this new approach (not mentioned in approach notes) is better than the selected approach.

RELEASE NOTES VERIFICATION

1)      Keep track of the version history and ensure that the release version mentioned is right.

2)      Revisions should not be mentioned in the release notes.(2.0.0.0 Rev1 and 2.0.0.0 Rev2 should be mentioned as 2.0.0.0 only in release notes)

3)      Release notes should specify briefly about all the new features implemented in the release (or the reason for release)

4)      For any new changes introduced, CR or SR number should be mentioned in release notes clearly.

1. Fixes for defects raised from site should be mentioned in release notes(CR/SR)
2. Internal defects (raised by ST) should not be mentioned in the release notes.

5)      Impact of  new  features on existing or other new features needs to be analysed and verified in the document.

FEATURE REQUIREMENT VERIFICATION

1)      Whenever a new requirement is raised/ recorded in the VSS, read and understand the feature/functionality mentioned in it.

2)      Derive all possible scenarios that can be caused by such a new feature and verify whether the feature requirement document is clearly specifying the required results for them.

3)      If not, escalate to the business team via team leads/manager and get the clarifications required.

It was a great day when I joined my first job. All my loved ones around rushing with best wishes and congrats! I was the happiest and my mind was full of dreams and plans… to learn… to capture heights… to excel… for a life… and all with my dear ones around.

Above is the dream of a graduate or any one who is entering into a professional life. Which in most cases will turn upside down. The life in  dreams and life in real differs a lot. Life is a mishap for all of them ?  Never! Most successful professionals in this world have the most healthy relations also. How can a professional lead  a healthy life keeping up all his/her obligations and with time for all  dear ones?

Here, its a place to share beautiful moments in a professional life… Provides Technical documents in simple language for new professionals a place to share some technical thoughts… a place to guide budding professionals… and a place to excel together as a mankind along with technology and nature!