1.
During testing, you find a bug and assigned it to
developer. But developer rejects the bug saying that it is not a defect. How
you will handle this situation?
First of all bugs should be logged
with proper reproducible steps, screen shots etc…
If developer rejects the bug, then
first thing to look out for is the reason or justification on why the bug was
rejected. If the justification is valid I would agree for the rejection.
However, if the reason is not justified then, I will go back and try to reproduce
the bug with the steps I had provided earlier. If it is still reproducible, I
shall reopen the bug with valid comments and will provide additional
information if I found any. Then I would go back to the developer asking for
justification on the rejection. At this point I shall include BA and technical
lead also is to take confirmation on the defects
2.
If there is no enough time for test execution,
how will you approach?
If there is
no enough time for testing, my first focus will be on the priority of the
requirements. The functionality which is the most important for the release
would be the first tested. Next I would focus on the areas where the
probability of finding defects is high. I would also analyze by test cases and
execute the high priority test cases first followed by medium and low if time
permits. If I know the application well and have previously worked on it, then
exploratory testing is a good approach when there is no much time. All these
should be approved by the Test Manager and should be documented in the test
strategy.
3.
What is QA role in each phase of SDLC?
It is always
a good approach to include QA from the first phase of SDLC. In requirement
planning and analysis phase QA gets involved in document review of requirements
(SRS). This will help in understanding the requirement right from the early
stages. In Design phase, the main task is to prepare the Test Plan, Test
Strategy. We can also come up with test scenarios in this phase. During
development phase QA will break the test scenarios into test cases. Test data,
test scripts, test environment setup etc… is done in this phase. Various kinds
of testing is performed during the test execution phase and defects are logged.
Defects summary reports and generated and sent to the team. We closely work
with the development team in closing the bug. During the maintenance phase test
summary report is sent to all the stakeholders and we also participate in the
lessons learnt sessions.
4.
What is exit criteria of testing? / When to stop
testing?
It is not
possible to ensure that an application is 100% free of defects. At some point
the testing should be stopped and we have to give a sign off so that the
application can be released. The exit criteria of testing will be mentioned in
the Test Plan before testing itself. We consider a lot of criteria to decide
when to stop the testing. For example the project timelines (we cannot test
endlessly, testing cycle should be estimated by keeping the project release
dates), All the defects have been addressed and closed, all the test cases have
been executed, traceability metrics is done (which means test cases have been
executed for each of the requirements). These are some of the factors which are
considered for stopping the testing.
5.
When do we start testing?
It is always
better to start the application right from the beginning of SDLC rather than
waiting for the testing phase. Because the cost of defect fix increases based
on the time it was found. Start of testing activities would start from Analysis
phase itself. There we will involve ourselves in understanding the
requirements. Once test plan, test cases etc… are written, it is always better
to get involved in the unit testing itself. In addition to in during testing
phase testers will not simply start testing. Testing would began when the
testing entry criteria are met. For example developers should stop the coding
and code freeze should be done. We cannot test if developers are working on the
application and have not finished their coding. Also they need to deploy the
code in a separate environment and proper release notes should be sent.
6.
Have you written any test plan? What are the
contents of test plan?
Yes I have
been involved in writing test plan. Test plan will contain the scope and all
the activities of testing. The main contents of test plan is testing scope,
testing approach, resources and testing schedule. In testing scope we will say
the testable and non-testable functionalities. In testing approach we would
mainly mention the testing environments, different kinds of testing, testing
cycles, the test cases which will be executed, testing data and scripts etc…It
will also say the test entry and exit criteria. Which means when testing will
be started and stopped. The roles and responsibilities of each resources would
be mentioned and testing schedule and timelines are also mentioned in the test
plan. In addition any risk/assumptions and dependencies are also mentioned in
the test plan.
7.
Explain STLC?
Software
Testing Life Cycle is a testing process which is executed in a sequential
manner to meet the testing goals. There are different phases of the STLC. Each
phase will have different activities and deliverables. Different phases of STLC
are
Test Planning
Phase: - Here testing objectives are defined and we come up with the
test plan. In this phase we will check on automation feasibility, we will
prepare the test plan and test effort estimation.
Test Analysis
and Design Phase: - In this phase we will do the test case designing, write test
scripts, prepare the test data. We will make the test environment ready
Test
implementation Phase: Actual testing is done in this phase. Different
types are testing is executed, test results are shared and bugs are logged.
Re-testing and bug closure is also done in this phase. We will come up with
test results and bug report in this phase
Test Exit
Phase: - In this phase we will verify if more testing is required.
Testing closure activities are carried out in this phase. Test summary reports
and testing metrics are created and shared to the stakeholders in this phase.
Test Closure
Phase: - Once the test exit criteria is reached, in this phase we will
archive all the documents that we have prepared from the beginning. So that it
can be used later. Lessons learnt sessions are done in this phase so that we
can know what went well and what can be improved so that upcoming releases are
smoother.
8.
Have you done any reviews for QA deliverables?
Yes, I have
reviewed QA deliverables mainly test plan and test cases. QA checklist is
maintained for each of the deliverables and the reviews will happen against the
checklist. First of all for all the deliverables that I prepare, I do a
self-review. Then I would give it to my team member who does the peer review.
Similarly I have also done peer reviews of my team mates documents. Before the
review walkthrough of the document is done so that it becomes easier to read
the document. My team maintains a checklist which needs to be given important
during the reviews. For example if I am reviewing the test plan, I ensure that
areas to be tested and non-testable requirements are properly documented. All
the test cases and test data is inserted, risk and dependencies are described
etc… During reviewing test cases my focus will be first to check the
requirement traceability, which means for each requirements if the test cases
are available. Next my focus will be on test coverage. I will check of all the
scenarios have been covered etc…
9.
What is the difference between verification and
validation?
Verification
means “Are we building the product right?” and validation means “Are we
building the right product?”
Which means
in verification the focus will be are we building the product based on the
requirements and design. Where as in validation the focus is on is the product
behaving properly (in terms of customer expectation).
Verification
examples: reviews, meetings
Validation
example: testing (different types of testing
10.
What is difference between regression and
retesting?
Regression
testing: Once the application is changed (for example after fixing a
defect or some enhancement is done), we need to test and ensure the existing
functionalities are working fine. This is called regression testing. For
example if a new text box is added to a web page. Then we have to ensure the
look and feel is not disturbed after introducing the text box also other fields
which were already there in the page is working as expected. This is regression
testing
Re-testing:- after a
defect is found by testers and then fixed by developers, it is again tested to
confirm that the original defect is actually fixed. Retesting is done to make
sure that the test cases which were failed earlier due to some defect is now
passing after the defect is fixed.
No comments:
Post a Comment