Q: How do you check the security of your application?
A: To check the security of an application, we can use security/penetration testing. Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage.
This type of testing usually requires sophisticated testing techniques.
Q: When testing the password field, what is your focus?
A: When testing the password field, one needs to verify that passwords are encrypted.
Q: What is the objective of regression testing?
A: The objective of regression testing is to test that the fixes have not created any other problems elsewhere. In other words, the objective is to ensure the software has remained intact.
A baseline set of data and scripts are maintained and executed, to verify that changes introduced during the release have not "undone" any previous code.
Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.
Q: What is the difference between software bug and software defect?
A: A ‘software bug’ is a nonspecific term that means an inexplicable defect, error, flaw, mistake, failure, fault, or unwanted behavior of a computer program.
Other terms, e.g. software defect and software failure, are more specific.
There are many who believe the word ‘bug’ is a reference to insects that caused malfunctions in early electromechanical computers (in the 1950s and 1960s), the truth is the word ‘bug’ has been part of engineering jargon for 100+ years. Thomas Edison, the great inventor, wrote the followings in 1878: "It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs" — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached."
Q: What is the definition of top down design?
A: Top down design progresses from simple design to detailed design. Top down design solves problems by breaking them down into smaller, easier to solve subproblems. Top down design creates solutions to these smaller problems, and then tests them using test drivers.
In other words, top down design starts the design process with the main module or system, then progresses down to lower level modules and subsystems.
To put it differently, top down design looks at the whole system, and then explodes it into subsystems, or smaller parts. A systems engineer or systems analyst determines what the top level objectives are, and how they can be met. He then divides the system into subsystems, i.e. breaks the whole system into logical, manageable-size modules, and deals with them individually.
Q: What is the difference between top down and bottom up design?
A: Top down design proceeds from the abstract (entity) to get to the concrete (design). Bottom up design proceeds from the concrete (design) to get to the abstract (entity).
Top down design is most often used in designing brand new systems, while bottom up design is sometimes used when one is reverse engineering a design; i.e. when one is trying to figure out what somebody else designed in an existing system.
Bottom up design begins the design with the lowest level modules or subsystems, and progresses upward to the main program, module, or subsystem.
With bottom up design, a structure chart is necessary to determine the order of execution, and the development of drivers is necessary to complete the bottom up approach.
Top down design, on the other hand, begins the design with the main or top-level module, and progresses downward to the lowest level modules or subsystems.
Real life sometimes is a combination of top down design and bottom up design.
For instance, data modeling sessions tend to be iterative, bouncing back and forth between top down and bottom up modes, as the need arises.
Q: What is the definition of bottom up design?
A: Bottom up design begins the design at the lowest level modules or subsystems, and progresses upward to the design of the main program, main module, or main subsystem.
To determine the order of execution, a structure chart is needed, and, to complete the bottom up design, the development of drivers is needed.
In software design – assuming that the data you start with is a pretty good model of what you’re trying to do – bottom up design generally starts with the known data (e.g. customer lists, order forms), then the data is broken into into chunks (i.e. entities) appropriate for planning a relational database.
This process reveals what relationships the entities have, and what the entities’ attributes are.
In software design, bottom up design doesn’t only mean writing the program in a different order, but there is more to it. When you design bottom up, you often end up with a different program. Instead of a single, monolithic program, you get a larger language, with more abstract operators, and a smaller program written in it.
Once you abstract out the parts which are merely utilities, what is left is much shorter program. The higher you build up the language, the less distance you will have to travel down to it, from the top. Bottom up design makes it easy to reuse code blocks.
For example, many of the utilities you write for one program are also useful for programs you have to write later. Bottom up design also makes programs easier to read.
Q: What is the purpose of a test plan?
A: Reason number 1: We create a test plan because preparing it helps us to think through the efforts needed to validate the acceptability of a software product.
Reason number 2: We create a test plan because it can and will help people outside the test group to understand the why and how of product validation.
Reason number 3: We create a test plan because, in regulated environments, we have to have a written test plan.
Reason number 4: We create a test plan because the general testing process includes the creation of a test plan.
Reason number 5: We create a test plan because we want a document that describes the objectives, scope, approach and focus of the software testing effort.
Reason number 6: We create a test plan because it includes test cases, conditions, the test environment, a list of related tasks, pass/fail criteria, and risk assessment.
Reason number 7: We create test plan because one of the outputs for creating a test strategy is an approved and signed off test plan document.
Reason number 8: We create a test plan because the software testing methodology a three step process, and one of the steps is the creation of a test plan.
Reason number 9: We create a test plan because we want an opportunity to review the test plan with the project team.
Reason number 10: We create a test plan document because test plans should be documented, so that they are repeatable.
Q: What is the difference between a test plan and a test scenario?
A: Difference number 1: A test plan is a document that describes the scope, approach, resources, and schedule of intended testing activities, while a test scenario is a document that describes both typical and atypical situations that may occur in the use of an application.
Difference number 2: Test plans define the scope, approach, resources, and schedule of the intended testing activities, while test procedures define test conditions, data to be used for testing, and expected results, including database updates, file outputs, and report results.
Difference number 3: A test plan is a description of the scope, approach, resources, and schedule of intended testing activities, while a test scenario is a description of test cases that ensure that a business process flow, applicable to the customer, is tested from end to end.
My innovation - Stay hungry, stay foolish. 