Software Testing
Testing is the process of evaluating a software and its component(s) with the intent to find whether it satisfies the specified requirements or not.Testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements.
Who Perform Software testing?
Software testing professionals who would like to understand the Testing Framework in detail along with its types, methods, and levels. This blog provides enough ingredients to start with the software testing process from where you can take yourself to higher levels of expertise.What are the prerequisites for Software testing?
Before continuing with Software Testing, you should have a basic understanding of the software development life cycle (SDLC). In addition, you should have a basic understanding of software programming using any programming language.Software testing provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. In simple words, testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual documented requirements.
As per ANSI/IEEE 1059 standard, Testing is defined as - A process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item.
Who does Testing?
It depends on the process and the associated stakeholders of the
project(s). In the IT industry, software companies have a team with
responsibilities to evaluate the developed software in context of the
given requirements.Moreover, developers also conduct testing which is called Unit Testing.
In most cases, the following professionals are involved in testing a system within their respective capacities:
- Software Tester
- Software Developer
- Project Lead/Manager
- End User
Note:- It is not possible to test the software at any time during its cycle. The next two sections state when testing should be started and when to end it during the SDLC.
When to Start Testing?
An early start to testing reduces the cost and time to rework and produce error-free software that is delivered to the client. However in Software Development Life Cycle (SDLC), testing can be started from the Requirements Gathering phase and continued till the deployment of the software. It also depends on the development model that is being used. For example, in the Waterfall model, formal testing is conducted in the testing phase; but in the incremental model, testing is performed at the end of every increment/iteration and the whole application is tested at the end.Testing is done in different forms at every phase of SDLC:
- During the requirement gathering phase, the analysis and verification of requirements are also considered as testing.
- Reviewing the design in the design phase with the intent to improve the design is also considered as testing.
- Testing performed by a developer on completion of the code is also categorized as testing.
When to Stop Testing?
Although there is no specific way to determine when to stop testing or we can say that software is 100% tested. The only ways by which we can say that we should stop testing the application is when:- Testing Deadlines
- Completion of test case execution
- Completion of functional and code coverage to a certain point
- Bug rate falls below a certain level and no high-priority bugs are identified
- Management decision
Verification & Validation
These two terms are very confusing for most people, who use them interchangeably. The following table highlights the differences between verification and validation.
S.N.
|
Verification
|
Validation
|
1
|
Verification addresses the concern:
"Are you building it right?" |
Validation addresses the concern:
"Are you building the right thing?" |
2
|
Ensures that the software system
meets all the functionality. |
Ensures that the functionalities meet
the intended behavior. |
3
|
Verification takes place first and
includes the checking for
documentation, code, etc.
|
Validation occurs after verification and
mainly involves the checking
of the overall product.
|
4
|
Done by developers.
|
Done by testers.
|
5
|
It has static activities, as it includes
collecting reviews,
walkthroughs, and inspections to
verify a software. |
It has dynamic activities, as it includes
executing the software against
the requirements.
|
6
|
It is an objective process and no
subjective decision should be
needed to verify a software.
|
It is a subjective process and involves
subjective decisions on how well
a software works.
|
There are some myths about software testing. Listed below are the some of the myth about software testing:-
Myth 1 : Testing is Too Expensive
Reality : There is a saying, pay less for testing during software development or pay more for maintenance or correction later. Early testing saves both time and cost in many aspects, however reducing the cost without testing may result in improper design of a software application rendering the product useless.Myth 2 : Testing is Time-Consuming
Reality : During the SDLC phases, testing is never a
time-consuming process. However diagnosing and fixing the errors
identified during proper testing is a time-consuming but productive
activity.
Myth 3 : Fully Developed Products are Tested
Reality : No doubt, testing depends on the source code but
reviewing requirements and developing test cases is independent from the
developed code. However iterative or incremental approach as a
development life cycle model may reduce the dependency of testing on the
fully developed software.
Myth 4 : Software can be 100% tested
Reality : It becomes an issue when a client or tester thinks that complete testing is possible. It is possible that all paths have been tested by the team but occurrence of complete testing is never possible. There might be some scenarios that are never executed by the test team or the client during the software development life cycle and may be executed once the project has been deployed.Myth 5 : Tested Software is Bug-Free
Reality : This is a very common myth that the clients, project
managers, and the management team believes in. No one can claim with
absolute certainty that a software application is 100% bug-free even if a
tester with superb testing skills has tested the application.
Myth 6 : Missed Defects are due to Testers
Reality : It is not a correct approach to blame testers for
bugs that remain in the application even after testing has been
performed. This myth relates to Time, Cost, and Requirements changing
Constraints. However the test strategy may also result in bugs being
missed by the testing team.
Myth 7 : Testers are Responsible for Quality of Product
Reality : It is a very common misinterpretation that only
testers or the testing team should be responsible for product quality.
Testers’ responsibilities include the identification of bugs to the
stakeholders and then it is their decision whether they will fix the bug
or release the software. Releasing the software at the time puts more
pressure on the testers, as they will be blamed for any error.
Myth 8 : Test Automation should be used wherever possible to Reduce Time
Reality : Yes, it is true that Test Automation reduces the
testing time, but it is not possible to start test automation at any
time during software development. Test automaton should be started when
the software has been manually tested and is stable to some extent.
Moreover, test automation can never be used if requirements keep
changing.
Myth 9 : Anyone can Test a Software Application
Reality : People outside the IT industry think and even
believe that anyone can test a software and testing is not a creative
job. However testers know very well that this is a myth. Thinking
alternative scenarios, try to crash a software with the intent to
explore potential bugs is not possible for the person who developed it.
No comments:
Post a Comment