Wednesday 10 July 2013

Software Testing Life Cycle

Software Testing Life Cycle Graphical Representation:



(A picture is more meaningful than thousand words)

Wednesday 6 February 2013

Classic Testing Mistakes




The role of testing
  • Thinking the testing team is responsible for assuring quality.
  • Thinking that the purpose of testing is to find bugs.
  • Not finding the important bugs.
  • Not reporting usability problems.
  • No focus on an estimate of quality (and on the quality of that estimate).
  • Reporting bug data without putting it into context.
  • Starting testing too late (bug detection, not bug reduction)
Planning the complete testing effort
  • A testing effort biased toward functional testing.
  • Under-emphasizing configuration testing.
  • Putting stress and load testing off to the last minute.
  • Not testing the documentation
  • Not testing installation procedures.
  • An over-reliance on beta testing.
  • Finishing one testing task before moving on to the next.
  • Failing to correctly identify risky areas.
  • Sticking stubbornly to the test plan.
Personnel issues
  • Using testing as a transitional job for new programmers.
  • Recruiting testers from the ranks of failed programmers.
  • Testers are not domain experts.
  • Not seeking candidates from the customer service staff or technical writing staff.
  • Insisting that testers be able to program.
  • A testing team that lacks diversity.
  • A physical separation between developers and testers.
  • Believing that programmers can't test their own code.
  • Programmers are neither trained nor motivated to test.
The tester at work
  • Paying more attention to running tests than to designing them.
  • Unreviewed test designs.
  • Being too specific about test inputs and procedures.
  • Not noticing and exploring "irrelevant" oddities.
  • Checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do.
  • Test suites that are understandable only by their owners.
  • Testing only through the user-visible interface.
  • Poor bug reporting.
  • Adding only regression tests when bugs are found.
  • Failing to take notes for the next testing effort.
Test automation
  • Attempting to automate all tests.
  • Expecting to rerun manual tests.
  • Using GUI capture/replay tools to reduce test creation cost.
  • Expecting regression tests to find a high proportion of new bugs.
Code coverage
  • Embracing code coverage with the devotion that only simple numbers can inspire.
  • Removing tests from a regression test suite just because they don't add coverage.
  • Using coverage as a performance goal for testers.
  • Abandoning coverage entirely.
Source: http://www.mobileqazone.com/

Tuesday 8 January 2013

Installation of Android App in Emulator


Installation of any App in Emulator:

Installing App in Emulators need the .apk file which we can find in the same project folder.
Path of the .apk file: workspace> project> bin\
There are different ways of installing Android App (.apk file) in emulators as mentioned below:

Way 1: If we are using Eclipse version 3.7.2, then on executing the Android project in Eclipse (without throwing any error) will automatically install the App (.apk file) in emulator (make sure the Emulator is open while executing the Eclipse Android project).

Way 2: We can also install the Android App (.apk file) through ‘adb’ (Android Debug Bridge).
adb is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device.

Path of adb: Drive\android-sdk-windows\platform-tools

‘adb’ used for installing any App in Android. As per mentioned command in the screenshot, is used for installing any app.

Installation Command is:

adb install demo.apk

[adb( command) install (command) demo.apk (path of.apk file of  demo android project)]
have a look on screenshot for reference:



Note: Emulator should be already opened while installing any App into Emulator