Your SlideShare is downloading. ×
0
Black Box Software Testing (Professional Seminar) <ul><li>Cem Kaner ,   J.D., Ph.D. </li></ul><ul><li>Professor of Compute...
Planning and Negotiating the Testing Project <ul><ul><li>The notes here focus on your process of negotiating resources and...
Planning the Testing Project <ul><li>Things you can do  very  early in the project: </li></ul><ul><ul><li>Analyze any requ...
Planning the Testing Project <ul><li>Things you can do  very  early in the project: </li></ul><ul><ul><li>Prepare for test...
Planning the Testing Project: First Principles <ul><ul><li>You  can’t  nail everything down. </li></ul></ul><ul><ul><li>Yo...
Planning the Testing Project: Deciding Your Depth of Testing <ul><li>You have three key objectives: </li></ul><ul><ul><li>...
Planning the Testing Project: Identify the Tasks <ul><li>Develop a project task list with your staff. Remember, you are lo...
Planning the Testing Project: Estimate the Time <ul><ul><li>1 Assign time estimates to each task. Invite programmers, mark...
Planning the Testing Project: Estimate the Time <ul><li>Don’t forget: </li></ul><ul><ul><li>Budget for meetings and admini...
Planning the Testing Project: Identify Dependencies & Milestones <ul><li>You can’t start reviewing the manual until you re...
Planning the Testing Project: Monitor Progress <ul><ul><li>Put the tasks and agreed-to durations on a timeline and review ...
Planning the Testing Project: Control Late-Stage Issues <ul><ul><li>Watch out for late changes. Encourage people to be cau...
Notes <ul><li>____________________________________________________________________________________________________________...
Project Planning <ul><li>Testing Impossible Software Under Impossible Deadlines </li></ul><ul><li>Presented at Software Te...
Introduction <ul><li>I didn’t come up with the idea for this talk--the STAR folk suggested it as something that I might be...
What Caused This Situation? <ul><li>So, let’s start with some questions about causation: </li></ul><ul><ul><li>Why is the ...
Why Do You Have So Little Time? <ul><li>A Few Possibilities </li></ul><ul><ul><li>Time-to-release drives competition </li>...
Quality Issues For This Customer? <ul><ul><li>In-house, “In-house” outsourced </li></ul></ul><ul><ul><li>External, custom ...
Political Approaches: Buying Time <ul><li>Many of the ideas in this section will help you if you’re dealing with a  single...
Buying Time:  Delaying a Premature Release -2 <ul><li>Take the high road </li></ul><ul><ul><li>“I want to see knives in th...
Buying Time:  Delaying a Premature Release -3 <ul><ul><li>Search for show-stoppers. If you can, dedicate a specialist with...
Buying Time:  Delaying a Premature Release -4 <ul><li>Do regular, effective status reporting. List: </li></ul><ul><ul><li>...
Signing Off on the Release? <ul><ul><li>Don’t sign off. </li></ul></ul><ul><ul><li>Don’t accept the authority to sign off....
Technical Approaches <ul><ul><li>Find reference docs (you can get lots of data, even if you can’t get specs.)  See the not...
Reusable Test Matrix
Group Management Approaches <ul><li>Can you add head count? </li></ul><ul><ul><li>Will they let you? </li></ul></ul><ul><u...
Notes <ul><li>____________________________________________________________________________________________________________...
Upcoming SlideShare
Loading in...5
×

ppt

177

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
177
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • You are NOT QA. You are a technical service group. The core of my strategy is to accept this. Your task is to convince the other stakeholders that it is in their best interest for you to do a better job. But you have to let them into your process, to the extent
  • Your stand is simple. Here are the tasks. They take the time they take. We’ll do what you want, but you have to add staff or cut tasks. Be realistic
  • The reason this succeeds is that you have opened up your process. the depth of testing and risk control is set by cross-functional business decisions estimates come fromthe technical staff, including the programmers areas of test come from outsiders as needed commitments are knowingly made by your staff Result is a unified effort to ship it, rather than mixed signals coming from different groups
  • Drucker: Management is the task of using people’s talents and making their weaknesses irrelevant
  • Transcript of "ppt"

    1. 1. Black Box Software Testing (Professional Seminar) <ul><li>Cem Kaner , J.D., Ph.D. </li></ul><ul><li>Professor of Computer Sciences </li></ul><ul><li>Florida Institute of Technology </li></ul><ul><li>Section:33 </li></ul><ul><li>Project Planning </li></ul><ul><li>Summer, 2002 </li></ul><ul><li>Contact Information: </li></ul><ul><li>[email_address] </li></ul><ul><li>www.kaner.com (testing website) </li></ul><ul><li>www.badsoftware.com (legal website) </li></ul><ul><li>I grant permission to make digital or hard copies of this work for personal or classroom use, with or without fee, provided that (a) copies are not made or distributed for profit or commercial advantage, (b) copies bear this notice and full citation on the first page, and if you distribute the work in portions, the notice and citation must appear on the first page of each portion, (c) each page bear the notice &quot;Copyright (c) Cem Kaner&quot; or if you changed the page, &quot;Adapted from Notes Provided by Cem Kaner&quot;. Abstracting with credit is permitted. The proper citation for this work is Cem Kaner, A Course in Black Box Software Testing (Professional Version) , Summer-2002 , www.testing-education.org . To copy otherwise, to republish or post on servers, or to distribute to lists requires prior specific permission and a fee. Request permission to republish from kaner@kaner.com. </li></ul>
    2. 2. Planning and Negotiating the Testing Project <ul><ul><li>The notes here focus on your process of negotiating resources and quality level. </li></ul></ul><ul><ul><li>Please see Testing Computer Software, Chapter 13 for a detailed discussion of planning and testing tasks across the time line of the project. </li></ul></ul>
    3. 3. Planning the Testing Project <ul><li>Things you can do very early in the project: </li></ul><ul><ul><li>Analyze any requirements documents for testability, ambiguity. </li></ul></ul><ul><ul><li>Facilitate inspection and walkthrough meetings. </li></ul></ul><ul><ul><li>Prepare a preliminary list of hardware configurations and start arranging for loaners. </li></ul></ul><ul><ul><li>Ask for testing support code, such as debug monitors, memory meters, support for testpoints. </li></ul></ul><ul><ul><li>Ask for a clear error handling message structure. </li></ul></ul><ul><ul><li>Discuss the possibility of code coverage measurement (which will require programmer support). </li></ul></ul>
    4. 4. Planning the Testing Project <ul><li>Things you can do very early in the project: </li></ul><ul><ul><li>Prepare for test automation. This involves reaching agreements in principle on breadth of automation and automation support staffing level. </li></ul></ul><ul><ul><li>Order automation support equipment. </li></ul></ul><ul><ul><li>Order external test suites. </li></ul></ul><ul><ul><li>Learn about the product’s market and competition. </li></ul></ul><ul><ul><li>Evaluate coding tools that facilitate automation (e.g. test 3rd party custom controls against MS-Test) </li></ul></ul>
    5. 5. Planning the Testing Project: First Principles <ul><ul><li>You can’t nail everything down. </li></ul></ul><ul><ul><li>You will face difficult prioritization choices, and many constraints will be out of your direct control. </li></ul></ul><ul><ul><li>You can influence several constraints by opening up your judgments to other stakeholders in the company. This is more than getting a sign-off. </li></ul></ul><ul><ul><li>Reality is far more important than your ability to cast blame. </li></ul></ul><ul><ul><li>Your task is to manage project-level risks. This includes risks to the project’s cost, schedule, and interpersonal dynamics, as well as to the product’s feature set and reliability. </li></ul></ul>
    6. 6. Planning the Testing Project: Deciding Your Depth of Testing <ul><li>You have three key objectives: </li></ul><ul><ul><li>1 Achieve a uniform and well-understood minimum level of testing. </li></ul></ul><ul><ul><li>2 Be explicit about the level of testing for each area: </li></ul></ul><ul><ul><ul><li>mainstream </li></ul></ul></ul><ul><ul><ul><li>guerrilla </li></ul></ul></ul><ul><ul><ul><li>formally planned </li></ul></ul></ul><ul><ul><ul><li>structured regression </li></ul></ul></ul><ul><ul><li>3 Reach corporate agreement on the level of testing for each area. Just like bug deferrals, depth-of-testing restrictions must rest on sound business decisions.This should not be your decision to make. </li></ul></ul>
    7. 7. Planning the Testing Project: Identify the Tasks <ul><li>Develop a project task list with your staff. Remember, you are looking for realism in estimates of complexity, difficulty, and time. </li></ul><ul><ul><li>Make the listing and estimation process public, and allow public comment. </li></ul></ul><ul><ul><li>Identify all potential sources of information. </li></ul></ul><ul><ul><li>List all main functional areas, and all other cross-functional approaches that you will take in testing the program. </li></ul></ul><ul><ul><li>List every task that appears to need more than 1/2 day. </li></ul></ul><ul><li>(Probably you will do this by a group brainstorming session on flipcharts, listing sources on one chart. Gather the sources. List areas and approaches on a few charts. Make one chart for each area of work, and list tasks for each chart. Tentatively assign times to each task, possibly by a museum tour.) </li></ul>
    8. 8. Planning the Testing Project: Estimate the Time <ul><ul><li>1 Assign time estimates to each task. Invite programmers, marketers, and project managers to walk through the charts and provide their own estimates. Explore the bases of differences. You might have underestimated a task’s complexity. Or you might be seeing a priority disagreement. Or wishful thinking. </li></ul></ul><ul><ul><li>2 Make your best-estimate task list. Provide the time needed to achieve formal, planned testing for each area. Include estimates for structured regression for key areas. This number is probably absurdly huge. </li></ul></ul><ul><ul><li>3 Add to the list your suggestions for time-cuts to guerrila-level and mainstream-level testing for selected areas. </li></ul></ul><ul><ul><li>4 Circulate your lists to all stakeholders, call one or more planning meetings, and reach agreements on the level of testing for each area. Keep cutting tasks and/or adding staff until you reach an achievable result. </li></ul></ul>
    9. 9. Planning the Testing Project: Estimate the Time <ul><li>Don’t forget: </li></ul><ul><ul><li>Budget for meetings and administrative overhead (10-30%). </li></ul></ul><ul><ul><li>Budget for bug regression (5-15%). </li></ul></ul><ul><ul><li>Budget for down time. </li></ul></ul><ul><ul><li>Budget for holidays and vacations. </li></ul></ul><ul><ul><li>Never develop a budget that relies on overtime. Leave the overtime free for discretionary additional work by the individual tester. </li></ul></ul><ul><ul><li>Don’t let yourself be bullied or embarrassed, and don’t bully or embarrass your staff, into making underestimates. To achieve a result, insist on cutting tasks, adding staff, or finding realistic ways to improve productivity. </li></ul></ul>
    10. 10. Planning the Testing Project: Identify Dependencies & Milestones <ul><li>You can’t start reviewing the manual until you receive it, right? List these dependencies and point out, in every project meeting, what is due to you that is not yet delivered and holding you up. </li></ul><ul><li>Try to reach verifiable, realistic definitions for each milestone. For example, if “gamma” is 6 weeks before release, the product can’t have more than 6 weeks of schedule risk at gamma. Negotiate a definition. </li></ul>
    11. 11. Planning the Testing Project: Monitor Progress <ul><ul><li>Put the tasks and agreed-to durations on a timeline and review progress of all staff every week. </li></ul></ul><ul><ul><li>When prerequisite materials aren’t provided, find other tasks to do instead. When you can’t meet the schedule, due to absent materials, publish new estimates. </li></ul></ul><ul><ul><li>When design changes invalidate your estimates, publish new estimates. </li></ul></ul><ul><ul><li>If you’re falling consistently behind (e.g. due to underestimated overhead), publish the problem and ask for fewer tasks, more staff, or some other realistic solution. </li></ul></ul><ul><ul><li>If one of your staff has trouble with an area, recognize it and deal with it. </li></ul></ul>
    12. 12. Planning the Testing Project: Control Late-Stage Issues <ul><ul><li>Watch out for late changes. Encourage people to be cautious about late bug fixes, and super-cautious about late design changes. </li></ul></ul><ul><ul><li>Provide interim and final deferred-bug reviews. </li></ul></ul><ul><ul><li>Take a final inventory of your testing coverage. </li></ul></ul><ul><ul><li>Carry out final integrity tests. </li></ul></ul><ul><ul><li>You may have to assess and reporting the reliability of the tested product. </li></ul></ul><ul><ul><li>Plan for post-release processes. Develop a release kit for product support. </li></ul></ul><ul><ul><li>Don’t forget the party. </li></ul></ul>
    13. 13. Notes <ul><li>______________________________________________________________________________________________________________________ ___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul>
    14. 14. Project Planning <ul><li>Testing Impossible Software Under Impossible Deadlines </li></ul><ul><li>Presented at Software Testing Analysis East, 1999 </li></ul>
    15. 15. Introduction <ul><li>I didn’t come up with the idea for this talk--the STAR folk suggested it as something that I might be able to provide a few insights into. After all, this is a chronic complaint among testers. . . . </li></ul><ul><li>Well, here goes. How should you deal with a situation in which the software comes to you undocumented on a tight deadline? </li></ul><ul><li>I think that the answer depends on the causes of the situation that you’re in. Your best solution might be technical or political or resume-ical. It depends on how you and the company got into this mess. If it is a mess. </li></ul>
    16. 16. What Caused This Situation? <ul><li>So, let’s start with some questions about causation: </li></ul><ul><ul><li>Why is the software undocumented? </li></ul></ul><ul><ul><li>Why do you have so little time? </li></ul></ul><ul><ul><li>What are the quality issues for this customer? </li></ul></ul>
    17. 17. Why Do You Have So Little Time? <ul><li>A Few Possibilities </li></ul><ul><ul><li>Time-to-release drives competition </li></ul></ul><ul><ul><li>Cash flow drives release date </li></ul></ul><ul><ul><li>Key fiscal milestone drives release date </li></ul></ul><ul><ul><li>Executive belief that you’ll never be satisfied, so your schedule input is irrelevant </li></ul></ul><ul><ul><li>Executive belief that testing group is out of control and needs to be controlled by tight budgets </li></ul></ul><ul><ul><li>Executive belief that you have the wrong priorities (e.g. paperwork rather than bugs) </li></ul></ul><ul><ul><li>Executive belief that testing is irrelevant </li></ul></ul><ul><ul><li>Structural lack of concern about the end customer, or </li></ul></ul><ul><ul><li>Maybe you have an appropriate amount of time. </li></ul></ul>
    18. 18. Quality Issues For This Customer? <ul><ul><li>In-house, “In-house” outsourced </li></ul></ul><ul><ul><li>External, custom </li></ul></ul><ul><ul><li>External, large package, packaged </li></ul></ul><ul><ul><li>External, mass-market, packaged </li></ul></ul><ul><ul><li>What is quality in this market? What are their costs of failure? </li></ul></ul><ul><ul><ul><li>User groups, Software stores, Sales calls, Support calls </li></ul></ul></ul><ul><li>Over the long term, a good understanding of quality in the market, and as it affects your company’s costs, will buy you credibility and authority. </li></ul>
    19. 19. Political Approaches: Buying Time <ul><li>Many of the ideas in this section will help you if you’re dealing with a single project that is out of control. </li></ul><ul><li>If your problem is structural (reflects policy or standard practice of the company), then some of these ideas will be counter-productive. </li></ul>
    20. 20. Buying Time: Delaying a Premature Release -2 <ul><li>Take the high road </li></ul><ul><ul><li>“I want to see knives in the chests, not in the backs.” </li></ul></ul><ul><ul><ul><li>Trip Hawkins, founding President, Electronic Arts </li></ul></ul></ul><ul><ul><li>Communicate honestly. </li></ul></ul><ul><ul><li>Avoid springing surprises on people. </li></ul></ul><ul><ul><li>Never sabotage the project. </li></ul></ul><ul><ul><li>Don’t become The Adversary : If you are nasty and personal, you will become a tool, to be used by someone else. And you will be disposable. </li></ul></ul>
    21. 21. Buying Time: Delaying a Premature Release -3 <ul><ul><li>Search for show-stoppers. If you can, dedicate a specialist within your group to this task. </li></ul></ul><ul><ul><li>Circulate deferred bug lists broadly. </li></ul></ul><ul><ul><li>Consider writing mid-project and late-in-project assessments of: </li></ul></ul><ul><ul><ul><li>extent of testing (by area) </li></ul></ul></ul><ul><ul><ul><li>extent of defects (by area, with predictions about level of bugs left) </li></ul></ul></ul><ul><ul><ul><li>deferred bugs </li></ul></ul></ul><ul><ul><ul><li>likely out of box experience or reviewers’ experience </li></ul></ul></ul>
    22. 22. Buying Time: Delaying a Premature Release -4 <ul><li>Do regular, effective status reporting. List: </li></ul><ul><ul><li>your group’s issues (deliverables due to you, things slowing or blocking your progress, etc., areas in which you are behind or ahead of plan) </li></ul></ul><ul><ul><li>project issues </li></ul></ul><ul><ul><li>bug statistics </li></ul></ul><ul><li>Find allies (think in terms of quality-related costs) </li></ul>
    23. 23. Signing Off on the Release? <ul><ul><li>Don’t sign off. </li></ul></ul><ul><ul><li>Don’t accept the authority to sign off. </li></ul></ul><ul><ul><li>Don’t pretend to be “QA” when you (obviously) are not. </li></ul></ul><ul><ul><li>Position yourself as a technical information provider. </li></ul></ul><ul><ul><ul><li>Publish pre-release reports that provide data on the stability of the product and the extent of completed testing </li></ul></ul></ul><ul><ul><ul><li>Publish a report that lays out the likely issues that will be raised by magazine reviewers (or other third parities) when they see the product </li></ul></ul></ul><ul><ul><ul><li>Let the people who want to ship prematurely own their responsibility. Your responsibility is to provide them with the information they need to make that decision. </li></ul></ul></ul>
    24. 24. Technical Approaches <ul><ul><li>Find reference docs (you can get lots of data, even if you can’t get specs.) See the notes on this in the section on Spec-Driven testing </li></ul></ul><ul><ul><li>Re-use materials across projects. </li></ul></ul><ul><ul><li>Plan for exploratory testing. </li></ul></ul><ul><ul><li>Do cost-effective automation. </li></ul></ul><ul><ul><li>Use tools to find bugs faster </li></ul></ul><ul><ul><ul><li>web page syntax checkers, spiders, etc. </li></ul></ul></ul><ul><ul><li>Facilitate inspections </li></ul></ul><ul><ul><ul><li>(Get those bugs out before they reach you.) </li></ul></ul></ul><ul><ul><li>Cover the obvious legal issues. </li></ul></ul>
    25. 25. Reusable Test Matrix
    26. 26. Group Management Approaches <ul><li>Can you add head count? </li></ul><ul><ul><li>Will they let you? </li></ul></ul><ul><ul><li>Can you absorb them? </li></ul></ul><ul><ul><ul><li>Do a work flow analysis to figure out what parts of each task could be split off and delegated to a newcomer. </li></ul></ul></ul><ul><li>Stay organized </li></ul><ul><ul><li>Use functional outlines </li></ul></ul><ul><ul><li>Or use a detailed project plan </li></ul></ul><ul><ul><li>Create and publish explicit coverage reports </li></ul></ul><ul><li>Get critical processes under control </li></ul><ul><ul><li>Example: release management </li></ul></ul>
    27. 27. Notes <ul><li>______________________________________________________________________________________________________________________ ___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul><ul><li>___________________________________________________________ </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×