Software QA/Testing Technical FAQs

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26   27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47 

What is SRS and BRS . and what is the difference between them?

Answer1:
SRS - Software Requirements Specification BRS - Business Requirements Specification

Answer2:
BRS - Biz Requirements Case
This doc has to be from the client stating the need for a particular module or a project. This basically tells you why a particular request is needed. Reasons have to be given. Mostly a lay persons document. This has to aproved by te Project Manager
SRS - Sq REq Specification
Follows the BRC after its approval etc. gives a detail func etc details about the project, requirement, use cases, refere..etc and how each module works in detal
your srs cannot start without a brc and an approval of the same

What should be done after a bug is found?
When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Qive some examples of
Low Severity and Low Priority Bugs
High Severity and Low Priority Bugs
Low Severity and High Priority Bugs
High Severity and High Priority Bugs ?

Answer1:
First know about severity and priority then its easy to decide Low or Medium or High
Priority-Business oriented
Severity-Effect of bug in the functionality
1. For example there is cosmetic change in the clients name and you found this bug at the time of delivery, so the severity of this bug is low but the priority is high because it affects to the business.
2. If you found that there is major crash in the functionality of the application but the crash lies in the module which is not delivered in the deliverables in this case the priority is low and severity is high.

Answer2:
Priority - how soon your business side needs a fix. (Tip: The engineering side never decides priority.)
Severity - how bad the bug bites. (Tip: Only engineers decide severity.)
For a high priority, low severity example, suppose your program has an easter egg (a secret feature) showing a compromising photo of your boss. Schedule this bug to be removed immediately.
Low priority, high severity example: A long chain of events leads to a crash that risks the main data file. Because the chain of events is longer than customers might probably reproduce, so keep an eye on this one while fixing higher priority things.
Testers should report bugs, the business side should understand them and set their priorities. Then testers and engineers should capture the bugs with automated tests before killing them. This reduces the odds they come back, and generally reduces "churn", which is bug fixes causing new bugs.

Answer3:
Priority is how important it is to the customer and if the customer is going to find it. Severity is how bad it is, if the customer found it.
High Priority low severity
I have a text editor and every 3 minutes it rings a bell (it is also noted that the editor does an auto-save every 3 minutes). This is going to drive the customer insane. They want it fixed ASAP; i.e. high priority. The impact is minimal. They can turn off the audio when using the editor. There are workarounds. Should be easy for the developer to find the code and fix it.
Low Priority High severity
If I press CRTL-Q-SHIFT-T, only in that order, then eject a floppy diskette from the drive it formats my hard drive. It is a low priority because it is unlikely a customer is going to be affected by it. It is high severity because if a customer did find it the results would be horrific.
High Priority High severity
If I open the Save As dialog and same the file with the same name as the Save dialog would have used it saves a zero byte file and all the data is lost. Many customers will select Save As then decide to overwrite the original document instead. They will NOT cancel the Save As and select Save instead, they will just use Save As and pick the same file name as the one they opened. So the likelihood of this happening is high; therefore high priority. It will cause the customer to lose data. This is costly. Therefore high severity.
Low Priority low severity
If I hold the key combination LEFT_CTRL+LEFT_ALT+RIGHT_ALT+RIGHT_CTRL+F1+F12 for 3 minutes it will display cryptic debug information used by the programmer during development. It is highly unlikely a customer will find this so it is low priority. Even if they do find it it might result in a call to customer service asking what this information means. Telling the customer it is debug code left behind; they didn't want to remove it because it would have added risk and delayed the release of the program is safer than removing it and potentially breaking something else. Answer4:
High Priority low severity
Spelling the name of the company president wrong
Low Priority High severity
Year end processing breaks ('cause its 6 more months 'till year end)
High Priority High severity
Application won't start
Low Priority low severity
spelling error in documentation; occasionally screen is slightly
misdrawn requiring a screen refresh

Give me five solutions to problems that occur during software development.
Solid requirements, realistic schedules, adequate testing, firm requirements and good communication.
1. Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements.
2. Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re-testing, changes and documentation. Personnel should be able to complete the project without burning out.
3. Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing.
4. Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure they're adequately reflected in related schedule changes. Use prototypes early on so customers' expectations are clarified and customers can see what to expect; this will minimize changes later on.
5. Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, tools of change management. Ensure documentation is available and up-to-date. Do use documentation that is electronic, not paper. Promote teamwork and cooperation.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26   27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47