For Better Understanding

Defect Management Process

  • Defect Prevention  – Implementation of techniques, methodology and standard processes to reduce the risk of defects.
  •  Deliverable Baseline  – Establishment of milestones where deliverable will be considered complete and ready for further development work.  When a deliverable is base lined, any further changes are controlled.  Errors in a deliverable are not considered defects until after the deliverable is base lined.
  •  Defect Discovery  – Identification and reporting of defects for development team acknowledgment.  A defect is only termed discovered when it has been documented and acknowledged as a valid defect by the development team member(s) responsible for the component(s) in error.
  •  Defect Resolution  – Work by the development team to prioritize, schedule and fix a defect, and document the resolution.  This also includes notification back to the tester to ensure that the resolution is verified.
  •  Process Improvement — Identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects.  Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process.
  •  Management Reporting  – Analysis and reporting of defect information to assist management with risk management, process improvement and project management.

Verification and Validation detail image

Validation(FDA): Establishing documented evidence which provides a high degree of assurance that a specific                            process will consistently produce a product meeting its predetermined specifications and                                 quality attributes. Contrast with data validation.

Validation, Verification, and Testing (NIST): Used as an entity to define a procedure of review, analysis, and                                                                       testing throughout the software life cycle to discover errors,                                                                            determine functionality, and ensure the production of quality                                                                            software.

Verification, Software (NBS): In general the demonstration of consistency, completeness, and correctness of                                              the software at each stage and between each stage of the development life                                                      cycle. See: validation, software.

Leave a comment

Posted by on September 14, 2013 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Basic reasons to automation testing.

Why to we required Automation testing?

Reusing the test scripts:

  • When you want to execute the regression test scripts after every build it makes more sense to automate them. In case of testing web based application there is a more need to automate as the test suite has to be run on various browsers like Internet Explorer, Firefox and other browsers.

Saves time:

  • Running unattended automated test scripts saves human time as well as machine time than executing scripts manually.

Better use of resource:

  • While automated scripts are running unattended on machines, testers can do more useful tasks.

Cost Saving:

  • On test engagements requiring a lot of regression testing, usage of automated testing reduces the people count and time requirement to complete the engagement and helps reduce the costs.

To Automate or Not to Automate?

  • It is not always advantageous to automate test cases. There are times when manual testing may be more appropriate.
  • For instance, if the application’s user interface will change considerably in the near future, then any automation would need to be rewritten. Also, sometimes there simply is not enough time to build test automation. For the short term, manual testing may be more effective. If an application has a very tight deadline, there is currently no test automation available, and it’s imperative that the testing get done within that time frame, then manual testing is the best solution.

Decide What Test Cases to Automate

  • Repetitive tests that run for multiple builds.
  • Tests that tend to cause human error.
  • Tests that require multiple data sets.
  • Frequently used functionality that introduces high risk conditions.
  • Tests those are impossible to perform manually.
  • Tests that run on several different hardware or software platforms and configurations.
  • Tests that take a lot of effort and time when manual testing.

Create Automated Tests that are Resistant to Changes in the UI

  • Automated tests created with scripts or keyword tests are dependent on the application under test.
  • The user interface of the application may change between builds, especially in the early stages. These changes may affect the test results, or your automated tests may no longer work with future versions of the application.
  • The problem is automated testing tools use a series of properties to identify and locate an object.
  • Sometimes a testing tool relies on location coordinates to find the object. For instance, if the location has changed, the automated test will no longer be able to find the object when it runs and will fail.
  • To run the automated test successfully, you may need to replace old names with new ones in the entire project, before running the test against the new version of the application.
  • However, if you provide unique names for your controls, it makes your automated tests resistant to these UI changes and ensures that your automated tests work without having to make changes to the test itself.
  • This also eliminates the automated testing tool from relying on location coordinates to find the control, which is less stable and breaks easily.
  • However, automation has specific advantages for improving the long-term efficiency of a software team’s testing processes.

Test automation supports:

  • Frequent regression testing
  • Rapid feedback to developers during the development process
  • Virtually unlimited iterations of test case execution
  • Customized reporting of application defects
  • Disciplined documentation of test cases
  • Finding defects missed by manual testing

Automated tests should be

Concise: Test should be as simple as possible and no simpler.

Self Checking: Test should report its results such that no human interpretation is necessary.

Repeatable: Test can be run repeatedly without human intervention.

Robust: Test produces same result now and forever. Tests are not affected by changes in the external                            environment.

Sufficient: Tests verify all the requirements of the software being tested.

Necessary: Everything in each test contributes to the specification of desired behavior.

Clear: Every statement is easy to understand.

Efficient: Tests run in a reasonable amount of time.

Specific: Each test failure points to a specific piece of broken functionality (e.g. each test case tests one                        possible point of failure).

Independent: Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.

Maintainable: Tests should be easy to modify and extend.

Traceable: Tests should be traceable to the requirements; requirements should be traceable to the tests.

Leave a comment

Posted by on September 14, 2013 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,



Test Plan

Android testing has several approaches:

- Test Android implementations: it’s the object of CTS

- Test mobile application: it’s the object of this document

To complete these tests, the user can use tools:

- CTS has automated the test plan

- This document proposes a test plan manually ran but during the event different solutions to partially automate these tests will be tested

1. Introduction

CTS are designed to test Android implementations.

This test plan is designed to test Android mobile applications. The test cases are intended to be ran manually. But some parts can be automated with specific tools.

2. Pre-Tests

This section provides general tests about launching the application.

2.1. Is the application launched successfully? Yes/No

2.2. Once launched, does the application gain control?


2.3. Does the installation of your application not interfere with the pre-installed applications?

Yes /No

2.4. Can you come back to the application main menu screen in less than 3 seconds?


Read the rest of this entry »

1 Comment

Posted by on September 29, 2012 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Improve Your Communication skills

Today we have many communications problem. So, I surfing some sites & to collect some data.

Here I published the some surfing’s collections for to improve your communications skills.
Please give me your true response if you have like or dislike.

Let’s Begin to Improve Your Communication Skills.

Improve Your Communication Skills

We all have people with whom we have to work to get things done.  Our ability to communicate with clients, customers, subordinates, peers, and superiors can enhance our effectiveness or sabotage us.  Many times, our verbal skills make the difference.  Here are 10 ways to increase your verbal efficacy at work:

  1. Develop your voice – A high whiney voice is not perceived to be one of authority.  In fact, a high soft voice can make you sound like prey to an aggressive co-worker who is out to make his/her career at the expense of anyone else.   Begin doing exercises to lower the pitch of your voice.  Here is one to start:  Sing — but do it an octave lower on all your favorite songs.  Practice this and, after a period of time, your voice will begin to lower.
  2. Slow down – People will perceive you as nervous and unsure of yourself if you talk fast.  However, be careful not to slow down to the point where people begin to finish your sentences just to help you finish.
  3. Animate your voice – Avoid a monotone.  Use dynamics.  Your pitch should raise and lower.  Your volume should be soft and loud.  Listen to your local TV news anchor; take notes.
  4. Enunciate your words – Speak clearly.  Don’t mumble.  If people are always saying, “huh,” to you, you are mumbling.
  5. Use appropriate volume – Use a volume that is appropriate for the setting.  Speak more softly when you are alone and close.  Speak louder when you are speaking to larger groups or across larger spaces.
  6. Pronounce your words correctly – People will judge your competency through your vocabulary.  If you aren’t sure how to say a word, don’t use it.
  7. Use the right words – If you’re not sure of the meaning of a word, don’t use it.  Start a program of learning a new word a day.  Use it sometime in your conversations during the day.
  8. Make eye contact – I know a person who is very competent in her job.  However, when she speaks to individuals or groups, she does so with her eyes shut.  When she opens them periodically, she stares off in a direction away from the listener.  She is perceived as incompetent by those with whom she consults.  One technique to help with this is to consciously look into one of the listener’s eyes and then move to the other.  Going back and forth between the two (and I hope they only have two) makes your eyes appear to sparkle.  Another trick is to imagine a letter “T” on the listener’s face with the cross bar being an imaginary line across the eye brows and the vertical line coming down the center of the nose.  Keep your eyes scanning that “T” zone.
  9. Use gestures – Make your whole body talk.  Use smaller gestures for individuals and small groups.  The gestures should get larger as the group that one is addressing increases in size.
  10. Don’t send mixed messages – Make your words, gestures, facial expressions, tone, and message match.  Disciplining an employee while smiling sends a mixed message and, therefore, is ineffective.  If you have to deliver a negative message, make your words, facial expressions, and tone match the message.

Improving your communication skills will improve your productivity.

Read the rest of this entry »


Posted by on September 26, 2012 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Sample of Mobile Test Cases

TEST 1 — Installation

Before starting the test round, use a file manager to note the free user space available on the phone. You will need this information in test 8.
1 Install the application being tested.The application must install without error.
2 During installation note the version number presented to the user.The version number must match that specified during submission.
3 Verify that the application has successfully installed on the device by navigating to the area on the phone where new applications are installed.The application should present one or more icon(s) on the phone.
For any submissions which do not appear obviously once installed, the submitter must include details in the submission statement of how successful installation can be verified.If the content does not appear obviously on the device once installed, and specific instructions are lacking in the submission statement, then this test will be failed.
Read the rest of this entry »

Posted by on July 11, 2012 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Software Development Life Cycle

Software Development Life Cycle

Software development approach and has a value proposition that includes faster turnaround times, trained pool of engineers with decent exposure to processes and best practices followed for the entire SDLC.

We have exposure on the following SDLC models :

  • Waterfall
  • V-Shaped
  • Structured Evolutionary Prototyping Model
  • Incremental
  • Spiral
  • Agile

A brief description of the various models mentioned above is given below. Along with the description, we have mentioned the strengths and discussed when a particular model is suited to you:

Read the rest of this entry »


Posted by on June 19, 2012 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Identifying sqa issues

Software Quality Assurance is a good practice that every large scale business should employ. IT related businesses have never hesitated to use SQA to ensure that the application they will release for their users or sell to their customers will live up to their expectations.

Sponsored Links

On the other hand, there are companies that has opted to forgo with the usage of SQA and relied on application testers just to make sure the application will never have internal errors. The SDLC on the other hand, will ensure the development of the application will work as planned.

Like other development plans, there are issues why developers and companies do not use SQA.

Read the rest of this entry »


Posted by on June 15, 2012 in Documents of software testing


Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,


Get every new post delivered to your Inbox.

Join 139 other followers

%d bloggers like this: