Interview Questions Part 4

-->

Q. What can be done if requirements are changing continuously?

A. QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused.

What can be done if requirements are changing continuously?
Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to...

• * Ensure the code is well commented and well documented; this makes changes easier for the developers.
• * Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.
• * In the project's initial schedule, allow for some extra time to commensurate with probable changes.
• * Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.
• * Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.
• * Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that's their job.
• * Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.
• * Design some flexibility into automated test scripts;
• * Focus initial automated testing on application aspects that are most likely to remain unchanged;
• * Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;
• * Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;
• * Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.

Q. What if the application has functionality that wasn't in the requirements?

A. It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.
If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.

Q.  Why are there so many software bugs?

A. Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.

• * There are unclear software requirements because there is miscommunication as to what the software should or shouldn't do.
• * Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.
• * Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
• * As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.
• * Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.
• * Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.
• * Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code, or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read.
• * Software development tools , including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.

Q. What is risk analysis? What does it have to do with Severity and Priority?

A. Risk analysis is a method to determine how much risk is involved in something. In testing, it can be used to determine when to test something or whether to test something at all. Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or under some circumstances if time runs out, not at all. It can also be used with defects. Severity tells us how bad a defect is: "how much damage can it cause?". Priority tells us how soon it is desired to fix the defect: "should we fix this and if so, by when?".
Companies usually use numeric values to calculate both values. The number of values will change from place to place. I assume a five-point scale but a three-point scale is commonly used. Using a defect as an example, Major would be Severity1 and Trivial would be Severity5. A Priority1 would imply that it needs to be fixed immediately and a Priority5 means that it can wait until everything else is done. You can add or multiply the two digits together (there is only a small difference in the outcome) and the results become the risk value. You use the event's risk value to determine how you should address the problem. The lower values must be addressed before the middle values, and the higher values can wait the longest.

Defect 12345
Foo displays an error message with incorrect path separators when the optional showpath switch is applied
Sev5
Pri5
Risk value (addition method) 10
Defect 13579
Module Bar causes system crash using derefenced handle
Sev1
Pri1
Risk value (addition method) 2
Defect 13579 will usually be addressed before 12345.

Another method for Risk Assessment is based on a military standard, MIL-STD-882. It describes the risk of failure for military hardware. The main area of interest is section A.4.4.3 and its children where they indicate the Assessment of mishap risk. They use a four-point severity rating: Catastrophic; Critical; Marginal; Negligible. They then use a five-point probability rating: Frequent; Probable; Occasional; Remote; Improbable. Then rather than using a mathematical calculation to determine a risk level, they use a predefined chart. It is this chart that is novel as it groups risks together rather than giving them discrete values. If you want a copy of the current version, search for MIL-STD-882D using Yahoo! or Google.

Q.   Give 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 ?

A.  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

If you have any quarries/feed back send me on - knowthetesting@gmail.com

Thank you

Ram