Tuesday, February 28, 2012
Latent Bug
Latent Bug is a bug which is not identified in present version and can be able to identified in later versions. Also called as Golden Bug.
Gap Analysis
The gap analysis process involves determining, documenting and approving the variance between business requirements and current capabilities.It is the comparison study of general expectation of performance in the industry and the level of performance at
which the company currently functions.
Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome (e.g. to turn the salary payment process from paper based to paperless with the use of a system).
Such analysis can be performed at the strategic or operational level of an organization.'Gap analysis' is a formal study of what a business is
doing currently and where it wants to go in the future. It can be conducted, in different perspectives, as follows:
Organization (e.g., human resources)
Business direction
Business processes
Information technology
Also
Banking and financial services organizations often ask this question, as they face the risk of missing or incompletely covered Business Requirements (BR) in Functional Specifications Documents (FSDs). This risk arises as business users may not always articulate their basic requirements under the misconception that development vendors know them already. However, that is not often the case because technology focused developers do not understand the nuances of banking like a domain specialist can.
Inconsistencies between Business Requirements and Functional Specifications result in critical requirement gaps later in the product life cycle. This often proves very costly for the client and the vendor, in terms of both monetary and reputation loss.
which the company currently functions.
Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome (e.g. to turn the salary payment process from paper based to paperless with the use of a system).
Such analysis can be performed at the strategic or operational level of an organization.'Gap analysis' is a formal study of what a business is
doing currently and where it wants to go in the future. It can be conducted, in different perspectives, as follows:
Organization (e.g., human resources)
Business direction
Business processes
Information technology
Also
Banking and financial services organizations often ask this question, as they face the risk of missing or incompletely covered Business Requirements (BR) in Functional Specifications Documents (FSDs). This risk arises as business users may not always articulate their basic requirements under the misconception that development vendors know them already. However, that is not often the case because technology focused developers do not understand the nuances of banking like a domain specialist can.
Inconsistencies between Business Requirements and Functional Specifications result in critical requirement gaps later in the product life cycle. This often proves very costly for the client and the vendor, in terms of both monetary and reputation loss.
Defect Leakage
Defect leakage occurs at the Customer or the End user side after the application delivery.After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect Leakage.This is also called as Bug Leakage.
Agile methodology over the Waterfall method
1. Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
2. Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.
2. Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.
Monday, February 27, 2012
Values of Agile Modeling
The five values of Agile Modeling (AM) are:
1.Communication : Models promote communication between your team and your project stakeholders as well as between developers on your team.
2.Simplicity : It’s important that developers understand that models are critical for simplifying both software and the software process—it’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.
3.Feedback : Kent Beck says it best in Extreme Programming Explained: “Optimism is an occupational hazard of programming, feedback is the treatment.” By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice.
4.Courage : Courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.
5.Humility : The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project. An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect. Huet Landry suggests the concept of "Other Esteem", instead of "Self Esteem", where you treat the opinions of others as if they have more value than yours. With this approach your first reaction to another's idea will be most positive.
1.Communication : Models promote communication between your team and your project stakeholders as well as between developers on your team.
2.Simplicity : It’s important that developers understand that models are critical for simplifying both software and the software process—it’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.
3.Feedback : Kent Beck says it best in Extreme Programming Explained: “Optimism is an occupational hazard of programming, feedback is the treatment.” By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice.
4.Courage : Courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.
5.Humility : The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project. An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect. Huet Landry suggests the concept of "Other Esteem", instead of "Self Esteem", where you treat the opinions of others as if they have more value than yours. With this approach your first reaction to another's idea will be most positive.
Difference Between Authorization And Authentication
Authentication is the process to test whether the specific user is allowed to use or login to the application.
And
Authorization we test whether the specific user allowed to access some controls or features of the system/application/software.
Eg: In an office automation tool, every employee can login to the application, but only accounts manager can access accounts related features, only HR manager or executive can access company information
And
Authorization we test whether the specific user allowed to access some controls or features of the system/application/software.
Eg: In an office automation tool, every employee can login to the application, but only accounts manager can access accounts related features, only HR manager or executive can access company information
Severity And Priority
Severity
1. The Severity status is used to explain how badly the deviation is affecting the build.
2. The Severity type is defined by the tester on the written test cases and functionality.
Ex : If an aaplication or a web page crashes when a remote link is clicked,in this case clicking the remote link by an user is rare but the impact of application crashing is severe,so the severity is high and priority is low.
Priority
1. The Priority status is set by the tester to the developer mentioning the time frame to fix a defect.If High priority is mentioned then the developer has to fix it at the earliest.
2. The priority status is set based on the customer requirements.
Ex : If the company name is misspelled in the home page of a website, then the priority is high and the severity is low to fix it
1. The Severity status is used to explain how badly the deviation is affecting the build.
2. The Severity type is defined by the tester on the written test cases and functionality.
Ex : If an aaplication or a web page crashes when a remote link is clicked,in this case clicking the remote link by an user is rare but the impact of application crashing is severe,so the severity is high and priority is low.
Priority
1. The Priority status is set by the tester to the developer mentioning the time frame to fix a defect.If High priority is mentioned then the developer has to fix it at the earliest.
2. The priority status is set based on the customer requirements.
Ex : If the company name is misspelled in the home page of a website, then the priority is high and the severity is low to fix it
Subscribe to:
Posts (Atom)
