|
|
Some Fundus
1) What is Testing?
Testing is the process of executing a program with the intent of finding errors – Myers.
A good software testing should:
(William Perry)
- Demonstrate the validity of the software at each stage in the system development life cycle.
- Determine the validity of the final system with respect to user needs and requirements.
- Examine the behavior of a system by executing the system on sample test data.
2) What are the primary and secondary goals of testing?
(CSTE CBOK)
Primary
- Determine whether the system meets specifications (product view)
- Determine whether the system meets business and user needs (customer view)
Secondary
- Raising issues
- Instilling confidence in the system
- Provide insight into the software delivery process
- Continuously improve the test process
3) What’s the goal of a software tester?
The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed – Ron Patton 4) What makes a good software tester?
(Ron Patton) – List of traits that most software testers should have:
- They are explorers: Software testers aren’t afraid to venture into unknown situations.
- They are troubleshooters: Software testers are good at figuring our why something doesn’t work. They love puzzles.
- They are relentless: Software testers keep trying. They may see a bug that quickly vanishes or is difficult to re-create. Rather than dismiss it as a fluke, they will try every way possible to find it.
- They are creative: Testing is obvious isn’t sufficient for software testers. Their job is to think up creative and even off-the-wall approaches to find bugs.
- They are (mellowed)perfectionists: They strive for perfection, but they know when it becomes unattainable an they’re OK with getting as close as they can.
- They exercise good judgment: Software testers need to make decisions about what they will test, how long it will take, and if the problem they’re looking at is really a bug.
- They are tactful and diplomatic: Software testers are always the bearers of bad news. They have to tell the programmers that their baby is ugly. Good software testers know how to do so tactfully and professionally and know how to work with programmers who aren’t always tactful and diplomatic.
- They are persuasive: Bugs that testers find won’t always be viewed as severe enough to be fixed. Testers need to be good at making their points clear, demonstrating why the bug does indeed need to be fixed, and the following through on making it happen.
5) Who is associated with Testing?
(William Perry)
Software customer: The party or department that contracts for the software to be developed.
Software user: The individual or group that will use the software once it is placed into production (this may be customer or it may be parties other than the customer).
Software developer: The individual or group that receives or assists in writing requirements, designing the software, building the software, and changing and maintaining the software as needed.
Software tester: The individual or group that performs the check functions on the software (These may be a subset of the developers, an independent group, or a combination of the two).
Information technology management: The individual or group with responsibility for fulfilling the information technology mission. Testing supports fulfilling that mission.
Senior organization management: The CEO or the organization and other senior executives who have the responsibility of fulfilling the organization mission. Information technology is an activity that supports fulfilling that mission.
Auditor: One or more individuals having the responsibility to evaluate the effectiveness, efficiency and the adequacy of controls in the information technology are. Testing is considered a control by the audit function.
6) What is Defect?
A defect is a variance from a desired product attribute. Testers look for defects.
There are two categories of defects:
1) Defect from product specification. The product built varies from the product specified. For example, the specifications may say that ‘a’ is to be added to ‘b’ to produce ‘c’. If the algorithm in the built product varies from the specification, it is considered to be defective.
2) Variance from customer / user expectation. This variance is something that the user wanted that is not in the built product, but also was not specified to be included in the built product. The missing piece may be a specification or requirements or the method by which the requirement was implemented may be unsatisfactory.
Defects generally, fall into one of the following three categories:
i) Wrong: The specifications have been implemented incorrectly. This defect is a variance from customer / user specification.
ii) Missing: A specified or wanted requirement is not in the built product. This can be a variance from specification, and indication that the specification was not implemented, or a requirement of the customer identified during or after the product was built.
iii) Extra: A requirement incorporated into the product that was not specified. This is always a variance from specification, but may be an attribute desired by the user of the product. However, it is considered a defect.
Defects vs Failures
- A defect is incorporated into the software system. It can be found within the software itself or in the supporting manuals and documentation. While the defect is a flaw in the software system, it has no impact until it affects the user/customer and the operational system.
- A defect that causes an error in operation or negatively impacts a user/customer is called a failure. The main concern with defects is that they will turn into failures. It is the failure that damages the organization.
- Some defects never turn into failures. On the other hand, a single defect can cause millions of failures. For example, a software defect that disrupts one million phone calls is one that causes one thousand failures.
7) When does a software bug occur?
(Patton)
A software bug occurs when one or more of the following five rules is true:
- The software doesn’t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn’t do.
- The software does something that the product specification doesn’t mention.
- The software doesn’t do something that the product specification doesn’t mention but should.
- The software is difficult to understand, hard to use, slow, or – in the software tester’s eyes – will be viewed by the end user as just plain not right.
8) 5 common problems in the software development process
- Poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems.
- Unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
- Inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash.
- Last minute changes - requests to pile on new features after development is underway; extremely common.
- Miscommunication - if developers don't know what's needed or customers have erroneous expectations, problems are guaranteed.
|