The document discusses reporting test results in software testing. It states that a test log and test incident report are prepared during and after test execution. A test log records events during testing like execution details, procedure results, and anomalous events. A test incident report documents any unexpected or unexplainable incidents that require follow-up. It provides details like a summary, description, impact, and identifiers. A test summary report summarizes the overall testing results and forms part of a project's historical records.

2. A social unit of people, systematically
structured and managed to meet a
need or to pursue collective goals on a
continuing basis.

3. All Organizations have a management
structure that determines the
relationships b/w functions and
positions and subdivides and delegates
roles, responsibilities and authority to
carry out defined tasks.

4. It is a framework within which an
Organization a aŶges it’s lives ofƌƌ
authorities and communications and
allocates rights and duties.

5. • Large, complex organization
s
often
require a taller hierarchy.
•In its simplest form, a tall
structure results in one long chain of
command similar to the military.
•As an organization grows, the number
of management levels increases and
the structure grows taller. In a tall
structure, managers form many ranks
and each has a small area of control.

7. • Flat structures have fewer management
levels, with each level controlling a
broad area or group.
• Flat organizations focus on empowering
employees rather than adhering to the
chain of command.
• By encouraging autonomy and self-
direction, flat structures attempt to
tap into employees creative talents and
to solve problems by collaboration.

9. • Virtual organization can be thought of as
a way in
which an organization uses
information and communication
technologies to replace or augment
some aspect of the organization.
• People who are virtually organized
primarily
interact by electronic means.
• For example, many customer help desks
link customers and consultants together
via telephone or the Internet and
problems may be solved without ever
bringing people together face-to-face.

10. • A boundary less Organizational
structure is a
contemporary approach in Organizational
design.
• It is an organization that is not defined
by, or limited to the horizontal, vertical
or external boundaries imposed by a
pre-defined structure.
• It behaves more like an organism
encouraging better integration among
employees and closer partnership with
stakeholders..

11. • Determines the manner and extent
to which roles, power and
responsibilities are delegated.
• Depends on objectives and
strategies.
• Acts as a perspective through which
iŶdi iduals ĐaŶ see theiǀ ƌ
o gaŶizatioŶ aŶd it’s eŶvi oŶŵeŶt.ƌ ƌ

12. • Impacts effectiveness and efficiency.
• Reduces redundant actions.
• Promotes teamwork.
• Improves communication.
• Contributes to success or failure.

13. • Divides work to be done in specific jobs
& dept.
• Assigns tasks and responsibilities
associated with individual jobs.
• Coordinates diverse organizational
tasks.
• Establishes relationship b/w individuals,
groups and departments.
• Establishes formal lines of authority.
• Allocates organizational resources.
• Clusters jobs into units.

15. The continuous line of
authority that extends from upper level of organization to
lowest level of organization and clarifies who reports to whom.
The rights inherent in a managerial
position to tell people what to do and expect them to do it.

16. The obligation or
expectation to perform. Responsibility
brings with it accountability. The
concept that a person should have
one boss and should report only to
him.
The assignment of
authority to another person to carry
out specific duties.

17. • When a company expands to
Supply goods or services
Produces variety of diff. products
Engage in several diff. markets
in such conditions the company can
adopt Departmentalization.

18. • Functional
• Product
• Customer
• Geographi
c
• Process

19. • Arranging the business according
to
what each
section or department does.

21. • Organizing according to the different
t
ypes of
products produced.

23. • Where different
customer
groups have different
needs.

25. • It is based on Geographic
Structure.

27. • Where products have to go
through
stages as they are made.

29. • Department can be staffed with
specialized
training.
• Shared management responsibility.
• Supervision is facilitated.
• Coordination within the department
is easier.

30. • Inter department documentation of
activities
is not possible.
• Decision-making becomes slow.
• Delays when there are problems.
• Accountability and performance are
difficult to monitor.

31. Misconceptions
about Software
Testing

32. Misconception
#ŗ:
ȁSoftwaretester is a loser developer
•It is often seen that people who were earlier trained to be
developers apply for tester positions now.
•They couldn’t find jobs as a developer, so they chose
to be testers. This is because they perceive testing as
an easy task that doesn’t require coding skills.
•However, the fact is that software testing and software
development are different jobs that requires different
skill sets and attitudes.
•If you are good at developing software’s doesn’t mean you
would be a good tester. Likewise, if you are a
good tester, doesn’t mean you cannot become a
software developer.

33. Misconception #Ř:
ȁAnyone can perform
software testing
monotonous job that requires no programming skills.
•What a software tester does is sit in front of a
computer, opens an application, clicks to and front to
see its working.
• However, testing requires a wide range of skills and
traits such as imagination, observation, passion, logical,
communication, debating and certainly includes coding
skills.
•To some extent, software testing can also be considered
as an art and apparently, not everyone can be an artist.
• Another misconception about software testing is that
anyone can perform it as it is an easy and

34. Misconception #ř: ȁManual
testing is outmoded. Now is
the time for automation
testing
• In the recent few years, automation testing services
indeed have become a hot topic.
• There are numerous discussions about how
manual testing is fading away and automation testing
being the new hero saving and fixing the software
testing world.

35. Misconception #ř:
ȁManualtesting
is outmoded. Now is the
time for automation
testing
replace manual testing.
•
.
• While automation testing is becoming more and more
powerful by showing its values, it is not designed to

36. Misconception #Ś:
ȁSoftware
testing is a cost-center and
not a
profit-center• There still exist companies who focus just on software
development only as they believe they have the best
developers who can write bug- free lines of codes.
• Also, the concept ‘developers build things, testers break it’
makes testing become less helpful.
• However, it is rightly said that testing is a cost-center. The
more the team tests, more it costs.
• But without testing, the organization may sooner or later
have to face the bigger costs of re-calling and fixing the units
delivered, plus the cost of upgrading the lost trust of the
customer to the reputation of the organization.

37. Misconception #ś: ȁ
You
missed bugs!
• This is one of the scariest phrases testers might get to hear from their
bosses.
• This comes from the misconception that a software tester is a
goalkeeper (or gatekeeper) whose job is to catch all
defects from escaping.
• Yes, all these defects could be caught if all
testing approaches, test types is applied readily.
techniques, test
• All this could be achieved when the testers have enough time and
money to employ.

38. Final verdict
• Misconceptions in software testing are not essentially
bad things; they are just a part of the learning process. We
may perceive things wrongly when we manage the way with
software testing and we also could comprehend
these misconceptions when we have more
experiences in software testing.
• The most important thing for a tester is to never stop
learning and keep sharpening his saws.
• Looking for an experienced software testing
company? Bugraptors is a CMMi5 testing company that
provides a manual and automation testing services..

39. REPORTING TEST
RESULTS

40. REPORTING TEST RESULTS
additional documents related to testing are
prepared during and after execution of the
tests. The IEEE Standard for Software Test
Documentation describes the following documents:
Test log
•prepared by the person executing the tests. It is a
diary of the events that take place during the test.
•It supports the concept of a test as a repeatable
experiment The test log is invaluable for use in
defect repair.
•It gives the developer a snapshot of the events
associated with a failure.
•The test log, in combination with the test
incident report which should be generated in
case of anomalous behavior, gives valuable clues
to the developer whose task it is to locate the
source of the Problem.
•prevent incorrect decisions based on incomplete
or erroneous test results.

41. In addition, the test log is valuable for
(i))regression testing that takes place in the development of
future releases of a software product, and
(ii)circumstances where code from a reuse library is to be reused. The
IEEE Standard for Software Test Documentation describes the
test log as a chronological record of all details relating to the
execution of its associated tests.
Test log has the following below;
Test Log Identifier
•Description - the tester should identify the items being tested, their
version/revision number, and their associated Test Item/Transmittal
Report.
•Activity and Event Entries - should provide dates and names of
test log authors for each event and activity
1.Execution description: 2.Procedure results:
3.Environmental information: 4.Anomalous events:
5.Incident report identifiers:

42. Test Incident report (problem report)
should record any event that occurs during the execution of the tests
that is unexpected, unexplainable, and that requires a follow-up
investigation.
The IEEE Standard recommends the following sections in the report:
Test Incident Report identifier Summary
Incident description - should describe time and date, testers,
observers, environment, inputs, expected outputs, actual outputs,
anomalies, procedure step, environment, and attempts to repeat. Impact
- A severity rating should be inserted here.
Test Summary Report
-summary of the results of the testing
efforts part of the project's historical database and
provides a basis for lessons learned as applied to
future projects

43. Test Summary Report identifier
Variances - Deviations and reasons for the deviation from the test plan, test
procedures, and test designs are discussed.
Comprehensiveness assessment - the document author discusses
the
comprehensiveness of the test effort as compared to test objectives and
test completeness criteria as described in the test plan.
Summary of results Evaluation
Summary of activities - Resource consumption, actual task durations, and
hardware and software tool usage should be recorded
Approvals
From the figure and the discussion in this chapter, it is apparent that
the preparation of a complete set of test documents that fully conform to
IEEE standards requires many resources and an investment of a great deal
of time and effort. Not all organizations require such an extensive set
of test-relateddocuments. Each organization should describe, as part
of its testing or quality standards, which test- related documents
should be prepared.

45. The Role of the Three Critical Groups in Testing
Planning and Test Policy Development

46. The Role of the Three Critical Groups in Testing Planning and Test
Policy Development
Three groups were identified as critical players in the testing process
Managers, Developers/Testers, and Users/Clients in TMM terminology
they are called the three critical views (CV)
Each group views
perspective that is
the testing process from a
different related to their
particular goals, needs, andrequirements.
The developers/testers work with
client/user groups on related activities and tasks that
concern user-oriented needs.
quality-
The focus is on soliciting client/user support, consensus, and
participation in activities such as requirements analysis, usability
testing, and acceptance test planning. In the following
paragraphs contributions to achievement of the managerial-
oriented maturity goals by the three critical views is Discussed.
For the TMM maturity goal, and Debugging
TMM recommends that

48. project and upper management:
Provide access to existing organizational goal/policy statements and
sample testing policies , and from other sources. These serve as policy
models for the testing and debugging domains.
•Provide adequate resources and funding to form the committees
(team or task force) on testing and debugging. Committee makeup is
managerial, with technical staff serving as co members.
•Support the recommendations and policies of the committee by:
—distributing testing/debugging goal/policy documents to project
managers, developers, and other interested staff,
—appointing a permanent team to oversee compliance and policy change
making.
•Ensure that the necessary training, education, and tools to carry out
defined testing/debugging goals is made available.

49. •Assign responsibilities for testing and debugging.
As representatives of the technical staff developers must ensure that
the policies reflect best testing practices, are implementable, receive
management support, and support among technical personnel.
The activities, tasks, and responsibilities for the developers/testers
include:
•Working with management to develop testing and debugging
policies and goals.
•Participating in the teams that oversee policy compliance and change
management.
•Familiarizing themselves with the approved set of testing/debugging
goals and policies, keeping up-to-date with revisions, and making
suggestions for changes when appropriate.
•When developing test plans, setting testing goals for each
project at each level of test that reflect organizational testing
goals and policies.
•Carrying out testing activities that are in compliance with
organizational policies.

50. • the goals and policies of users and clients reflect the
ensure customer/client/userorganizations efforts to
satisfaction.
Upper management supports this goal by:
•Establishing an organization wide test planning committee with
funding.
•Ensuring
standards support test planningwith commitment of
resources,
that the testing policy statement and quality
tools, templates, and training.
•From the user/client point of view support for test planning is in
the form of articulating their requirements clearly, and supplying
input to the acceptance test plan.
Process and the Engineering Disciplines:
One of our major focuses as engineers is on designing,
implementing, managing, and improving the processes related to
software development. Testing is such a process.
•An engineer can serve as the change agent, using his education in
the area of testing to form a process group or to join an
existing one.
•The engineer can initiate the implementation of a defined
testing process by working with management and users/clients
toward achievement of the technical and managerial-oriented
maturity goals.

51. Test Management and Organizational
Structures

52. Test Management and Organizational Structures
Besides a test group's name and its assumed responsibilities, there's
another attribute that greatly affects what it does and how it works with
the project team. That attribute is where it fits in the company's overall
management structure. A number of organizational structures
are possible, each having its own positives and negatives. Some are
claimed to be generally better than others, but what's better for one
may not necessarily be better for another. If you work for any length of
time in software testing, you'll be exposed to many of them. Here
are a few common examples.
Figure shows a structure often used by small (fewer than 10 or so people)
project teams. In this structure, the test group reports into
the Development Manager, the person managing the work of
the programmers. Given what you've learned about software testing,
this should raise a red flag of warning to you the people writing the code
and the people finding bugs in that code reporting to the same person has
the potential for big problems.
Figure. The organizational structure for a small project often has the test
team reporting to the development manager.

53. There's the inevitable conflict of interest. The Development
Manager's goal is to have his team develop software. Testers
reporting bugs just hinder that process. Testers doing their job well
on one side make the programmers look bad on the other. If the
manager gives more resources and funding to the testers, they'll probably
find more bugs, but the more bugs they find, the more they'll crimp
the manager's goals of making software.
Despite these negatives, this structure can work well if
the development manager is very experienced and realizes that his
goal isn't just to create software, but to create quality software.
Such a manager would value the testers as equals to the
programmers. This is also a very good organization for
communications flow. There are minimal layers of management and
the testers and programmers can very efficiently work together.
Figure shows another common organizational structure where both
the test group and the development group report to the manager of
the project. In this arrangement, the test group often has its own
lead or manager whose interest and attention is focused on the test
team and their work. This independence is a great advantage
when critical decisions are made regarding the software's quality.
The test team's voice is equal to the voices of the programmers
and other groups contributing to the product.
Figure In an organization where the test team reports to the
project manager, there's some independence of the testers from the
programmers.

54. The downside, however, is that the project manager is making the
final decision on quality. This may be fine, and in many industries and
types of software, it's perfectly acceptable. In the development of high-
risk or mission-critical systems, however, it's sometimes beneficial to
have the voice of quality heard at a higher level. The organization shown in
Figure represents such a structure.
Figure. A quality assurance or test group that reports to
executive management has the most independence, the most authority,
and the most responsibility

55. In this organization, the teams responsible for software quality
report directly to senior management, independent and on
equal reporting levels to the individual projects. The level of authority is
often at the quality assurance level, not just the testing level. The
independence that this group holds allows them to set standards
and guidelines, measure the results, and adopt processes that span
multiple projects. Information regarding poor quality (and good quality)
goes straight to the top.
Of course, with this authority comes an equal measure of
responsibility and restraint. Just because the group is independent from
the projects doesn't mean they can set unreasonable and difficult-to-
achieve quality goals if the projects and users of the software don't
demand it. A corporate quality standard that works well on database
software might not work well when applied to a computer game. To
be effective, this independent quality organization must find ways to
work with all the projects they deal with and temper their enthusiasm for
quality with the practicality of releasing software.

56. Keep in mind that these three organizational structures are just
the Insimplified examples of the many types possible and that
positives and negatives discussed for each can vary
widely.software development and testing, one size doesn't necessarily fit all,
and what works for one team may not work for another. There
are, however, some common metrics that can be used to measure,
and guidelines that can be followed, that have been proven to
work across different projects and teams for improving their quality
levels.

57. Test
Planning

58. Test
Planning
• A plan is a document that provides
approach for achieving a set of goals.
a framework or
• Milestones are tangible events that are expected to occur
at a certain time in the project’s lifetime. Managers use
them to determine project status.
58

59. The planner usually includes the following essential high-
level items.
•Overall test objectives.
As testers, why are we testing, what is to be achieved by the
tests, and what are the risks associated with testing this
product?
•What to test (scope of the tests).
What items, features, procedures, functions, objects,
clusters, and subsystems will be tested?
•Who will test. Who are the personnel responsible for the
tests?
•How to test.
What strategies, methods, hardware, software tools, and
techniques are going to be applied? What test documents
and deliverable should be produced?
•When to test. What are the schedules for tests? What
items need to be available?
•When to stop testing.
It is not economically feasible or practical to plan to test until
all defects have been revealed. This is a goal that testers can
never be sure they have reached. Because of budgets,
scheduling, and customer deadlines, specific conditions
must be outlined in the test plan that allow testers/managers
to decide when testing is considered to be complete.
59

60. Hierarchy of
Test
Plans
60

61. Test Plan
Componen
t
s
61

62. Responsibilitie
s
The staff who will be responsible for
test-related tasks should be identified.
This includes personnel who will be:
transmitting the software-under-test;
developing test design specifications, and
test
cases;
executing the tests and recording results;
tracking and monitoring the test efforts;
checking results;
interacting with developers;
managing and providing equipment;
developing the test harnesses;
interacting with the users/customers.
62

63. Testing Costs
Test costs that should included in the plan
are:costs of planning and designing the tests;
costs of acquiring the hardware and
software necessary for the tests (includes
development of the test harnesses);
costs to support the test environment;
costs of executing the tests;
costs of recording and analyzing test results;
tear-down costs to restore the environment.
63

64. Approaches to test cost estimation
E = a (size in KLOC)b
E is estimated effort in man-months
a and b are constants that can be
determined from tables provided by
Boehm or by the organization
itself based on its own historical data 7

65. Test Plan
Attachment
sT e s t D e s i g n S p e c i f i
t i o n s
c
a
Test Design
Specification Identifier
Features to Be Tested
Approach Refinements
Test Case Identification
Pass/Fail Criteria
8

66. Test Plan
Attachments

70. Test Plan Components
Test Plan:
It is a high level document in which how to perform testing
is described. The Test Plan document is usually prepared by the
Test Lead or Test Manager and the focus of the document is to
describe what to test, how to test, when to test and who will do
what test.
The plan typically contains a detailed understanding of what
the eventual workflow will be.
•Master test plan: A test plan that typically addresses multiple
test levels.
•Phase test plan: A test plan that typically addresses one test
phase.

71. •Test Plan Template contains following components:
1.Introduction—A brief summary of the product being tested. Outline
all the functions at a high level.
Overview of This New System Purpose of this Document Objectives of
System Test
1.Resource Requirements—
Hardware– List of hardware requirements
Software–List of software requirements: primary and secondary OS
Test Tools—List of tools that will be used for testing.
Staffing
1.Responsibilities—
List of QA team members and their responsibilities
1.Scope—
2.In Scope
3.Out Scope
1. Training—
List of t aiŶiŶg’s e ui edƌ ƌ Ƌ ƌ
1. References—
List the related documents, with links to them if available, including
the following:
1.Project Plan
2.Configuration Management Plan

72. 8. Features Not to Be Tested—
1.List the features of the software/product which will not be tested.
2.Specify the reasons these features won’t be tested.
9. Test Deliverables—
1.List of the test cases/matrices or their location 2.List of the features to be
automated
10. Approach—
1.Mention the overall approach to testing.
2.Specify the testing levels [if it’s a Master Test Plan], the testing types, and the
testing methods [Manual/Automated; White Box/Black Box/Gray Box
11.Dependencies—
1.Personnel Dependencies 2.Software Dependencies 3.Hardware Dependencies
4.Test Data & Database 12.Test Environment—
1.Specify the properties of test environment: hardware, software, network etc.
2.List any testing or related tools.
13.APPROVALS—
1.Specify the names and titles of all persons who must approve this plan.
2.Provide space for signatures and dates.
14.Risks and Risk management plans—
1.List the risks that have been identified.
2.Specify the mitigation plan and the contingency plan for each risk.
15.Test Criteria— 1.Entry Criteria 2.Exit Criteria 3.Suspension Criteria
16.Estimate—
•Size
•Effort
•Schedule