Think Publication

“A person should not be too honest. Straight trees are cut first and Honest people are screwed first.
(Do not be very upright in your dealings for you would see by going to the forest that straight trees are cut down while crooked ones are left standing.)”

“Even if a snake is not poisonous, it should pretend to be venomous.”

“The biggest guru-mantra is: Never share your secrets with anybody. ! It will destroy you.”

“There is some self-interest behind every friendship. There is no Friendship without self-interests. This is a bitter truth.”

“Before you start some work, always ask yourself three questions - Why am I doing it, What the results might be and Will I be successful. Only when you think deeply and find satisfactory answers to these questions, go ahead.”

“As soon as the fear approaches near, attack and destroy it.”

“Once you start a working on something, don’t be afraid of failure and don’t abandon it. People who work sincerely are the happiest.”

“The fragrance of flowers spreads only in the direction of the wind.

But the goodness of a person spreads in all direction.”

“Whore s don’t live in company of poor men, citizens never support a weak company and birds don’t build nests on a tree that doesn’t bear fruits.”

“God is not present in idols. Your feelings are your god. The soul is your temple.”

“A man is great by deeds, not by birth.”

“Never make friends with people who are above or below you in status. Such friendships will never give you any happiness.”

“Treat your kid like a darling for the first five years. For the next five years, scold them. By the time they turn sixteen, treat them like a friend. Your grown up children are your best friends.”

“Education is the best friend. An educated person is respected everywhere. Education beats the beauty and the youth.”

“The world’s biggest power is the youth and beauty of a woman.”

Test Plan reflects your entire project testing schedule and approach.

Test Plan is a management planning document that describes:

1. How the testing will be done?

2. Who will do it?

3. What will be tested?

4. How long it will take?

5. What the test coverage will be?

Test plan document formats can be as varied as the products and organizations to which they apply, but there are three major elements of a test strategy that should be described in the test plan:

Test Coverage - Test coverage in the test plan states what requirements will be verified during what stages of the product life

Test Methods - Test methods in the test plan state how test coverage will be implemented

Test Responsibilities - Test responsibilities include what organizations will perform the test methods and at each stage of the product life

IEEE Standard Test Plan Structure (IEEE 829-1998)

This standard specifies the following test plan outline:

- Test plan identifier

-  Introduction

-  Test items

-  Features to be tested

- Features not to be tested

- Approach

- Item pass/fail criteria

- Suspension criteria and resumption requirements

- Test deliverables

- Testing tasks

- Environmental needs

- Responsibilities

- Staffing and training needs

- Schedule

- Risks and contingencies

- Approvals

Test Plan Identifier:

- A unique identifier

Introduction:

- Summary of the items and features to be tested

- Need for and history of each item (optional)

- References to related documents such as project authorization, project plan, QA plan, configuration management plan, relevant policies, relevant standards

- References to lower level test plans

Test Items:

- Test items and their version

- Characteristics of their transmittal media

- References to related documents such as requirements specification, design specification, users guide, operations guide, installation guide

- References to bug reports related to test items

- Items which are specifically not going to be tested (optional)

Features to be Tested:

- All software features and combinations of features to be tested

- References to test-design specifications associated with each feature and combination of features

Features Not to Be Tested:

- All features and significant combinations of features which will not be tested

- The reasons these features won’t be tested

Approach:

- Overall approach to testing

- For each major group of features of combinations of features, specify the approach

- Specify major activities, techniques, and tools which are to be used to test the groups

- Specify a minimum degree of comprehensiveness required

- Identify which techniques will be used to judge comprehensiveness

- Specify any additional completion criteria

- Specify techniques which are to be used to trace requirements

- Identify significant constraints on testing, such as test-item availability, testing-resource availability, and deadline

Item Pass/Fail Criteria:

- Specify the criteria to be used to determine whether each test item has passed or failed testing

Suspension Criteria and Resumption Requirements

- Specify criteria to be used to suspend the testing activity

- Specify testing activities which must be redone when testing is resumed

Test Deliverables:

- Identify the deliverable documents: test plan, test design specifications, test case specifications, test procedure specifications, test item transmittal reports, test logs, test incident reports, test summary reports

- Identify test input and output data

- Identify test tools (optional)

Testing Tasks:

- Identify tasks necessary to prepare for and perform testing

- Identify all task interdependencies

- Identify any special skills required

- Environmental Needs

- Specify necessary and desired properties of the test environment: physical characteristics of the facilities including hardware, communications and system software, the mode of usage (i.e., stand-alone), and any other software or supplies needed

- Specify the level of security required

- Identify special test tools needed

- Identify any other testing needs

- Identify the source for all needs which are not currently available

Responsibilities:

- Identify groups responsible for managing, designing, preparing, executing, witnessing, checking and resolving

- Identify groups responsible for providing the test items identified in the Test Items section

- Identify groups responsible for providing the environmental needs identified in the Environmental Needs section

Staffing and Training Needs:

- Specify staffing needs by skill level

- Identify training options for providing necessary skills

Schedule:

- Specify test milestones

- Specify all item transmittal events

- Estimate time required to do each testing task

- Schedule all testing tasks and test milestones

- For each testing resource, specify its periods of use

Risks and Contingencies:

- Identify the high-risk assumptions of the test plan

- Specify contingency plans for each

Approvals:

- Specify the names and titles of all persons who must approve the plan

- Provide space for signatures and dates

What is Usability Testing?

Usability testing is a technique for ensuring that the intended users of a system can carry out the intended tasks efficiently, effectively and satisfactorily.

When is Usability testing appropriate?

Usability testing it is carried out pre-release so that any significant issues identified can be addressed.
Usability testing can be carried out at various stages of the design process. In the early stages, however, techniques such as walkthroughs are often more appropriate.
Usability testing is not a substitute for a human centered design process.

What are the things keep in mind while doing Usability Testing?

There is no such specific guideline to follow; I am mentioning some points which helpful to get overall perspective of the software while testing.
Tester should always keep in mind that System or application fulfill following criteria while developing:

Mirror of Real World
Try to get 100% fitness
Work for Real customer
Believe in KEIS (Keep It Simple)
Prevention is better than cure
Consistent in everywhere
Ready to help

Mirror of Real World:
systems should be mirror of real world means it should be user centric and speak world language for example while developing a banking application need to use word which is used worldwide like credit and debit rather than borrow or any some other phrase.
So before start testing get some domain knowledge and prepare glossary for the domain and check that application is it fit with real world or not?

Try to get 100% fitness:
Always keep in mind that there is no 100% error free screens.
Some time usability designer and product management team has lack of domain knowledge or they are not so close to end customers so sometime application screens are very far away from real problem and do not fulfill all expectations, so always think around the problem and end customer and try to achieve 100% fitness.

Work for Real customer:
while testing an application behave and think like end customer and try to identify all representative tasks. Ideally, these should derive from scenarios or use cases developed earlier in the design process. Have a clear definition of when a task is complete.

Believe in KEIS (Keep It Simple):
Things always keep simple in application. Flow of application, business logic and all UI (User Interface) Screens should be simple and understandable for layman. Screen should be clearly defined and mirror of deliverables, Don’t provide too many information in screen, Just deliver all necessary information which is required to perform particular task on the screen.

Prevention is better than cure:
Prevention of error/exception always better then cure so application should be designed as a smart systems where all errors and exceptions handled properly, Application should have sufficient error message and warning messages which describe exact input and desired output of the systems.

Consistent in everywhere:
application should follow platform conventions, all UI screens should be simple and consistent so user always be in same platform and able to understand use of application.
All Error messages and other messages, guidelines and business term should be consistent and reflect same meaning.

Ready to help:
Application provides help document to end user so they can able to understand application and make it more useful in their life. System should display help message or guidelines for valid input also show proper error message and wait messages if any process is running behind the application.

These are ten general principles for user interface design. They are rules of thumb in usability guidelines.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Algorithm is set of rules to perform certain operation in certain conditions.
While creation of algorithms developers follow some rules and mathematic computations which calculate or predict the application behavior in certain condition.
Testing an algorithms are not so simple, testing of algorithms need same kind of attention and treatment as it gets while creation.

As I spoke in my previous article, Tester is responsible for deliverables, same rule apply here also because most of time after implementation of algorithms no body bother to find exact working of algorithms.
So success of algorithms not only depends on development team but also on testing team.

There is no exact rules to test any algorithms, its depend on case by case and how you approach to find solution.
I am trying to figure out some set of guidelines which can be helpful while testing an algorithm

Whenever you get some task then approach should be:

Read as much as you can
Start Discussion with Developer team
Analyze Conditions and scope of algorithms
Find Right Approach
Create your own data set
Start Testing
Interact with Dev team while testing

Read as much as you can:
The fundamental rules of testing says, whenever any testing comes to the door tester should read end to end specification or use case document but in algorithm testing tester need to pay more attention to understand exact rules and calculations, Don’t read formally, read 2-4 times, research on local resource or internet and read same kind of algorithms, as much you read as much you understand of algorithms.

(Note: Here calculations mean mathematical, logical and conditional rules and computations.)

Start Discussion with Developer team:
So you did you home work and now it is time to give some shape of your effort so start talking with dev team and try to convey what you understand by design doc. Start discussion and actively participle and voice your concern.
Some time dev team did not mentioned all conditions and limitations of algorithms so ask all conditions and limitations also ask boundary conditions and do some boundary value analysis of algorithms.
As more you ask as more you get from them and as more you get as more you understand.

Analyze Conditions and scope of algorithms:
Third step is to analyze scope of the algorithm and to evaluate all conditions, evaluate all inner conditions, outer conditions and boundary conditions. Most of algorithms fail or does not work properly on boundary conditions or on set of boundary data. So tester need to pay attention to find the area where algorithms can be leak.

Find Right Approach
Take some time and try to find right approach as solution, there are many way to solve any problem just try to figure out which is most suitable and simple method for you to cover all scenario because some time we know which is the more flexible and fast method but don’t approach that method if you’re not so comfortable with it.
I am saying again we are going to test an algorithm which is one time job so don’t try to find any shortcut. Adopt that approach where you are comfortable, no issues if take more time and effort but end of the work you will be assure about correctness and precision of the algorithms.

Thumb rule: don’t try to find any shortcuts.

Create your own data set:
Now be relax, you did 60% of your task. Now think and evaluate properly and create you data set where you will test algorithm. Success of testing within the scheduled time depends on how efficiently you create your data set. Cover all possible conditions, especially boundary conditions.
Prepare test result so you can compare algorithms output from known results.

Start Testing
Start testing on single true conditions and then start testing on multiple conditions and rules,
don’t forget to include negative test cases, negative or wrong testing approach give an idea that how algorithm is robust and can able to handle all exception properly or not?

Interact with Dev team while testing
Interact with dev team and describe your approach include following points
1. How you tested?
2. What are the test data and test results?
3. How you compare results?
4. What are conclusions?

So you will get the idea how things are going and you are in right direction or not?
Take feedback from them and ask to advice so you can make better test case and do more carful testing because developer is the guy who knows how algorithms should behave in all conditions and exceptions.

Please feel free to highlight any hide area where need to more focus, I will appreciate your feedback.

If you are looking for best and free eBooks for

• Engineering
• Medical
• Computer
• Software
• Business
• Career
• Management
• Java
• .Net
• Testing

And many more………….

Visit the site “http://knowfree.net”

This is really very cool site with thousand of free eBooks. This site doesn’t require any kind of registration. I think you’ll find it quite pleasant.

Why I suggest only this site?

When I search “Free eBooks” on Google, I found lots of link for Free eBooks on Google main page, but when I browse these links none of them was up to the mark. Someone suggest me to use http://knowfree.net for free eBooks.

I personally use this site and found very use full. If you find same, please leave a comment for me.