|
|
|
Software Development Company India |
Testing |
|
|
|
Testing involves operation of a system or application under controlled conditions
and evaluating the results (eg, 'if the user is in interface A of the application
while using hardware B, and does C, then D should happen'). The controlled conditions
should include both normal and abnormal conditions. Testing should intentionally
attempt to make things go wrong to determine if things happen when they shouldn't
or things don't happen when they should. It is oriented to 'detection'. Organizations
vary considerably in how they assign responsibility for Quality Assurance and testing.
Sometimes they're the combined responsibility of one group or individual. Also common
are project teams that include a mix of testers and developers who work closely
together, with overall Quality Assurance processes monitored by project managers.
It will depend on what best fits an organization's size and business structure.
|
|
|
|
|
Does every software project need testers?
|
|
|
|
|
While all projects will benefit from testing, some projects may not require independent
test staff to succeed.
|
|
|
|
|
Which projects may not need independent test staff? The answer
depends on the size and context of the project, the risks, the development methodology,
the skill and experience of the developers, and other factors. For instance, if
the project is a short-term, small, low risk project, with highly experienced programmers
utilizing thorough unit testing or test-first development, then test engineers may
not be required for the project to succeed.
|
|
|
|
|
In some cases an IT organization may be too small or new to have a testing staff
even if the situation calls for it. In these circumstances it may be appropriate
to instead use contractors or outsourcing, or adjust the project management and
development approach (by switching to more senior developers and agile test-first
development, for example). Inexperienced managers sometimes gamble on the success
of a project by skipping thorough testing or having programmers do post-development
functional testing of their own work, a decidedly high risk gamble.
|
|
|
|
|
For non-trivial-size projects or projects with non-trivial risks, a testing staff
is usually necessary. As in any business, the use of personnel with specialized
skills enhances an organization's ability to be successful in large, complex, or
difficult tasks. It allows for both a) deeper and stronger skills and b) the contribution
of differing perspectives. For example, programmers typically have the perspective
of 'what are the technical issues in making this functionality work?'. A test engineer
typically has the perspective of 'what might go wrong with this functionality, and
how can we ensure it meets expectations?'. Technical people who can be highly effective
in approaching tasks from both of those perspectives are rare, which is why, sooner
or later, organizations bring in test specialists |
|
|
|
|
A sample testing cycle Although testing varies between organizations, there
is a cycle to testing : |
|
|
|
|
Requirements Analysis : Testing should begin in the
requirements phase of the software development
life cycle. During the design phase, testers work with developers in
determining what aspects of a design
are testable and under what parameter those tests work.
|
|
|
|
|
Test Planning : Test Strategy, Test Plan(s), Test
Bed creation.
|
|
|
|
|
Test Development : Test Procedures, Test Scenarios,
Test Cases, Test Scripts to use in testing
software.
|
|
|
|
|
Test Execution : Testers execute the software based
on the plans and tests and report any errors found
to the development team.
|
|
|
|
|
Test Reporting : Once testing is completed, testers
generate metrics and make final reports on their test
effort and whether or not the software tested is ready for release.
|
|
|
|
|
Retesting the Defects |
|
|
|
|
Not all errors or defects reported must be fixed by a software development team.
Some may be caused by errors in configuring the test software to match the development
or production environment. Some defects can be handled by a workaround in the production
environment. Others might be deferred to future releases of the software, or the
deficiency might be accepted by the business user. There are yet other defects that
may be rejected by the development team (of course, with due reason) if they deem
it |
|
|
|
|
|
|
|
|
|
|
|
|