Role of a tester in defect prevention and defect detection

Better Testing, Testing Tips | 2 comments


In this post we will discuss the role of a tester in these phases and how to testers can prevent more defects in Defect Prevention phase and how testers can detect more bugs in Defect Detection phase
 
Role of a tester in defect prevention and defect detection.
 
Defect prevention – In Defect prevention, developers plays an important role. In this phase Developers do activities like – code reviews/static code analysis, unit testing, etc. Testers are also involved in defect prevention by reviewing specification documents. Studying the specification document is an art.
 
While studying specification documents, testers encounter various queries. And many times it happens that with those queries, requirement document gets changed/updated.
Developers often neglect primary ambiguities in specification documents in order to complete the project; or they fail to identify them when they see them. Those ambiguities are then built into the code and represent a bug when compared to the end-user’s needs. This is how testers help in defect prevention.
 
We will discuss “How to review the specification document?” in a separate post.
Defect Detection & Defect Prevention
 
Defect Detection – In Defect detection, role of a tester include Implementing the most appropriate approach/strategy for testing ,preparation/execution of effective test cases and conducting the necessary tests like – exploratory testing, functional testing, etc.
To increase the defect detection rate, tester should have complete understanding of the application. Ad hoc /exploratory testing should go in parallel with the test case execution as a lot of bugs can be found through that means.
 
Defect Prevention early in the cycle has the following benefits:
  • Faster Delivery – Accelerate the release cycles – Ensure smooth deliveries.
  • Software Development free of Hassles
  • Reduces Rework
  • Reduces costs
  • Increase Customer satisfaction


Testing any website with slow internet connection

Better Testing, Performance Testing, Testing Tips

Chrome can be used to simulate a slow connection.
Install Chrome if it is not already installed on your system. After that, open a new tab and press CTRL + SHIFT + I to bring up the developer tools window, or click on the hamburger icon, then More tools, then Developer tools.

Now click on Network section – a drop-down menu of pre-configured speeds appears, which you can use to simulate a slow connection.

Chrome Network throttling
To add your own custom values, click the Add button under Custom. To create a new profile, click the Add Custom Profile button.

This is an excellent tool that is integrated into Chrome that you can use to determine the load time of your website on slower connections. Please feel free to leave a comment if you have any questions. Enjoy!

Prioritization of Test Cases

Better Testing, Testing Tips


Importance of prioritizing
There is no limit to how much testing we could do. We cannot test everything, exhaustive testing (testing all combinations of inputs and preconditions) is impractical, so we must prioritise. It is easy enough to identify far more test cases than we will ever have time to execute so we need an approach to selecting a subset of them. Selecting test cases at random is not an effective strategy. We need to use a more intelligent approach that helps identify which tests are most important. In short, we must prioritize our tests.

Prioritize tests so that whenever you stop testing you have done the best testing in the time available.

How to prioritize
The principle is that we must adopt a prioritization scheme for selecting some tests above others. As we start from highest priority and scan the tests in decreasing order of priority, there must be a point at which we reach the first test that is of too low a priority to be done. All tests of a lower priority still are de-scoped. There are many different criteria that can be used to prioritize tests and they can be used in combination. Possible ranking criteria include the following:

  • Ask the end-user to prioritize the requirements (and test those first)
  • Test first the areas of the software that have had most faults in the past
  • Test most those areas of the software that are most complex or critical.
  • Tests that would find the most severe failures.
  • Tests that would find the most visible failures.
  • Tests that would find the most likely faults.
     
Reference: http://goo.gl/HL40G (iseb notes)


Excuses for testers when bugs are caught in later testing cycles/UAT/Production

Test Management, Testing Tips


[Note – This post might not be helpful for testers who work in independent test companies]
One of the biggest pain-point for testers is that whenever a bug is caught in UAT or caught in later stages then blame is unfairly put on testing teams. This further results into unfair yearly reviews and appraisals of testing teams.In many mid size companies, less value is given to testing teams. Testing culture lacks in those companies. Management should understand that testing team is “also responsible” [not “only responsible”] when a bug is caught in production.

Testers should be proactive and should be able deal with such situations. They should have the excuses ready when they are asked “HOW DID YOU MISS THAT BUG?”. In this post, I am writing some excuses so that testers can put themselves on safer side whenever bugs are found in UAT/Production. Each excuse depends upon a situation, so give below excuses carefully.

Excuse 1: Bug is missed because this scenario is not in the test case. These test cases are reviewed and approved by Business Analyst/Product Manager/XXXX person.

Excuse 2: Testing team already reported a similar bug which is not fixed yet. That’s why we got this new bug in UAT/Production. [most common excuse].

Excuse 3: The bug is occurring because of the last minute changes in the application by development team. Project management team should come up with a strategy so that we can avoid last minute changes.

Excuse 4: Bug is missed because this scenario/rule is not mentioned in the requirement document [most common excuse].

Excuse 5: Testing is done in hurry because enough time was not given to testing team. Project management team should be proactive and should make an effective plan.

Excuse 6: Bug is missed because we (testers) did not test this functionality in later testing cycles. This functionality is not included in the testing scope.

Excuse 7: Bug is missed because we tested only that functionality which we got in the list of impacted areas. Whenever a change is made in the existing functionality then Development Team/Development Lead/Manager should give testing team the detailed list of impacted areas so that all impacted areas can be tested and bugs can be avoided in UAT/Production.

Excuse 8: This was the same bug which we got in our testing environment but at that time it was inconsistent. We reported it once but then both dev and testing teams were not able to replicate again.

Excuse 9: This bug might be occurring because Developers were fixing the bugs on Testing environment on the same time when testers were testing. Testing team cannot be blamed. Project management team should come up with a strategy so that we can avoid changes directly on QA/Testing environment.

Excuse 10: Why this is a bug? This is working as designed. Please show us which section of requirement/specification document states this rule. [Attn testers: Make this excuse only when you are sure that there are discrepancies in specification document].

Excuse 11: This bug is occurring when user selects a specific value in the dropdown/test data. It is working fine with other values. Exhaustive testing is impossible.

Well these are not actually excuses. These can be the actual reasons why an application is shipped to client with major bugs.

Do you have good excuses 🙂 ? Share in comments
Like this post? –>

Long Live Testers | Happy Testing


User Acceptance Testing Concepts

Testing Tips, User Acceptance Testing


.. Continuing the Beginners Guide to Software Testing series

User Acceptance testing is –

  • the formal testing done on the system to ensure that it satisfies the acceptance criteria before the system is put into production. [Most of the times it is done by users/clients]
  • the incremental process of approving or rejecting the system during development and maintenance.

Acceptance Testing checks the system against the requirements of the user. It is done by real people using real data and real documents to ensure ease of use and functionality of systems. Users who understand the business functions run the tests as given in the acceptance test plans, including installation and Online help Hardcopies of user documentation are also being reviewed for usability and accuracy. The testers/users formally document the results of each test, and provide error reports, correction requests to the developers.



User Acceptance testing Myth – Passing the UAT acknowledges that the system is fit for use and also it acknowledges the process of development was adequate.


Reality: “Passing the acceptance tests does not necessarily mean the software is acceptable. That’s just the first hurdle to acceptance.” – via @the Three Amigos – Better Software Magazine [NOVEMBER/DECEMBER 2011]

Now a days we are using Agile and Incremental software development models. So Acceptance testing should be the ongoing activity. It needs to involved in the development process and approximate correction need to be made whenever it fails the acceptance criteria.

Ongoing Software Acceptance Testing enables:

  • Early detection of software problem.
  • Early consideration of user needs during software development.
  • Ensure user are involved in system and acceptance criteria.
  • Decision involved based on the results.