jerry.testing

Few Good Scenarios for ATM Mechines

2008-08-25T03:24:00.000-07:00

1.To verify ATM card Insertion
2.To verify ATM card Insertion in wrong angle
3.To verify invalid ATM card Insertion
4.To verify Language selection
5.To verify Pin entry
6.To verify invalid Pin entry
7.To verify invalid Pin entry 3 times
8.To verify Account Type selection
9.To verify Invalid Account Type selection with respectiveto inserted card
10.verify withdrawal option selection
11.verify Amount entry
12.verify Amount entry with wrong denominations(fr eg:00.999Rs)
13.verify withdrawal success operation
14.Verify operation when our entered amount is grater thanpossible balance
15.Verify operation when our entered amount is grater thanday limit
16.Verify when our ATM have lack of Amount
17.Verify when our ATM have network problem
18.Verify Current transaction No.exceeded than day limit
19.Verify operation with exceeded delay in betweenoperations in ATM
20.Verify Cancel after insert card
21.Verify Cancel after Language selection
22.Verify Cancel after Pin entry
23.Verify Cancel after Amount type selection
24.Verify Cancel after withdrawal operation
25.Verify Cancel after Amount entry
26.Verify correction of Amount during entry
27.Verify after successful transaction If customer doesn'ttake the money

QTP Life Saving Tips _1

2008-08-22T19:55:00.000-07:00

QTP Testing Process

1. Preparation for Test Flow and Recording.
2. Recording/Scripting Test flow.
3. Enhancing the Test.
4. Debugging the Test.
5. Setup the Test inside FrameWork.
6. Running the Test.
7. Analyzing the Result.

Types of Recording

1. Context Sensitive (Based on Objects)
Window("Index Page").Dialog("Sign In User").WinButton("SignIn").Click
2. Analog (Based on Mouse Moments)
Window("Index Page").RunAnalog "Track 3"
3. Low Level (Based on Coordinates)
Window("Index Page").Dialog("Sign In User").WinButton("SignIn").Click 25,5

Object Repository

1. Local Object Repository
Action specific, can not call in other actions and tests
2. Shared Object Repository
Test Specific, can call in other actions and tests.

Object Identification

1. Normal Identification
First Mandatory Properties and then Assistive Properties until getting the unique description. If both fails QTP will user Ordinal Identifiers (Location and Index).
2. Smart Identification
If this enabled QTP will not use Ordinal Identifiers and will use Base Filter Properties and Optional Filter Properties respectively.

Two Good SQL Tricks

2008-07-14T05:19:00.000-07:00

Actually these two things are not Tricks for SQL Masters, but for dummies like me hope this will help a lot.
1. To find the specific table name, with a part of table name we can use this Query
sp_tables '%USR%' This will give u the result of table name with "USR" word.
2. Once you got a table name to get all the details. Just use the table name in ur editor then select the table name fully and press "ALT+F1". This will give you the details about the table, its contents and options inside.

Good Day

Font Setting for QTP Scripting

2008-06-21T21:49:00.001-07:00

Here is the best Font setting for QTP Scripting.

The need of Team Support in Testing

2008-05-18T22:16:00.001-07:00

Do not distrub a sleeping Tester

2008-04-29T03:01:00.000-07:00

Cool Change Request flow for a good project

2008-02-19T00:23:00.000-08:00

Top Ten Mistakes in Web Design

2008-02-14T02:31:00.000-08:00

Here is a good link on Top mistakes in Web Design...
worth to know as tester.
http://www.useit.com/alertbox/9605.html

Thanks to Jakob.

Cheers,
Jerald

Screen Resolutin for ur web application

2008-02-14T02:27:00.000-08:00

Here is a good link to understand Resolution test
http://www.useit.com/alertbox/screen_resolution.html

If u want to do a little resolution test online....
Here we go...use this link...
http://www.webconfs.com/web-page-screen-resolution.php

Cheers,
Jerald

Few ideas for Regression Test

2008-02-14T02:22:00.000-08:00

REGRESSION TEST

Regression test case selection methodology

Code Base Regression Test Selection (CBRTS)
Specification Based Regression Test Selection (SBRTS)
Risk Based Regression Test Selection (RBRTS)

Regression test Folder Structure

Module Level structure (Just with Modules)
Easy to Add
Easy to locate in high level
Easy to maintain in high level

UC level structure under Module (Existing structure of System Tests)
Easy to maintain in functional level / module level
Easy to locate in low level
Easy to maintain in low level
Easy use in future

Regression test selection from System tests

1. Risk Based Tests from every UC.
2. Test case that covers the primary objective / summary outline of the UC.
3. Test case that covers the priority E2E functionalities from that UC.
4. Integrated E2E test cases from UC level.

Conditions to be followed on Regression Test selection

1. Selected tests must cover all the major functionalities of the module.
2. No –ve tests in RT.
3. Selected tests must not concentrate on data type / data change / screen design.
4. Selected tests must not get affected on DBCR/UICR.
5. Selected Regression tests must cover most of the UAT cases.
6. Selected tests must cover all the possible High Risk areas in functional flow.

An wonderful note on ET (Exploratory Testing)

2008-01-23T21:48:00.000-08:00

Hi All,

Here is a good note on ET by Galvan...
http://www.testingreflections.com/node/view/6455

and one more...
http://shrinik.blogspot.com/2007/12/exploratory-testing-challenged-part-i.html

Cheers,
Jerald

MOBILE CAR LOCK AND START

2008-01-14T03:10:00.000-08:00

Suddenly I got this idea in my mind. Now a days most of the people got car they always carry the car key with their remote lock where ever they go. Hence the things we have to carry get increased, like wallet, credit card, mobile phone, car key with remote lock and watch etc. To reduce that I got this simple idea "Mobile Car Lock".

The usual remote car lock works with IR or Blue tooth. Since now a day's most of the mobile comes with both the features, we can use our mobile itself as our car's remote key. But for that we can not use the same hardware mechanism inside our mobile. The problem is if u changed your mobile then u have to change your car lock or its mechanical part inside your mobile.

To avoid that, we can develop a little java mobile program (kind of program that can be run in all mobiles not only in symbian) which will transfer a secure key though IR/BT to the Lock system installed in the car and unlock the car.

More then that we can even make that as car's key, so that we can lock/unlock our car and even start our car with our mobile. Its not necessary to carry our car key and its remote lock everywhere.

If you changed our mobile or lost it, simply install the application in your new mobile and enter your secret code on that. It will lock/unlock/start your car.

If some car company or Lock company created that then this will be an awesome tool to use with.

This may have lot of security issues with that, but they r after all comes with the existing locking mechanisms. More that that we can improve the locking program and make it more secure.

Cheers,
Jerald

Wanna test your webpage live load time.

2008-01-10T22:30:00.000-08:00

Here is a little tool free in the web. You can find the page loading time in live and come to an conclusion on your page size, image weight and interface load time.
http://www.hashemian.com/tools/page-load-timer.htm

Also find some usefull tools in that site
http://www.hashemian.com/tools/

Thanks to Hashemian.

Cheers,
Jerry

Wishing You All a Blessed New Year

2007-12-31T19:28:00.000-08:00

With Love,
Jerry

How to write a good Defect Report

2007-12-21T01:32:00.000-08:00

Here is the key(s)

Be very specific when describing the bug. Don’t let there be any room for interpretation. More concise means less ambiguous, so less clarification will be needed later on.
Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.
Don’t be repetitive. Don’t repeat yourself. Also, don’t say things twice or three times.
Try to limit the number of steps to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.
Start describing with where the bug begins, not before. For example, you don't have to describe how to load and launch the application if the application crashes on exit.
Proofreading the bug report is very important. Send it through a spell checker before submitting it.
Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)
Please make sure that you use sentences. This is a sentence. This not sentence.
Don’t use a condescending or negative tone in your bug reports. Don’t say things like "It's still broken", or “It is completely wrong”.
Don’t use vague terms like “It doesn’t work” or “not working properly”
If there is an error message involved, be sure to include the exact wording of the text in the bug report. If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.
Once the text of the report is entered, you don’t know whose eyes will see it. You might think that it will go to your manager and the developer and that’s it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans. The point is that the bug report is your work product, and you should take pride in your work.

Hope this will help you to write a proper Bug Report.

Thanks to Pavan for his help on this.

Cheers,

-jerry-

DETAILS ON DEFECT TRACKING

2007-12-21T01:15:00.000-08:00

Here r few things to be included in the Defect Tab.
(M) - Mandatory
(D) - Default Appearance

DETAILS ON DEFECT TRACKING

Use Case Package (M)
Test Case (M)
Detected By (M) (D)
Detected On Date (M) (D)
Defect Type
Status (M) (D)
Detected in Version (M)
Build Number (M)
Assigned To (M) (D)
Business Impact / Severity (M)
Priority
Reproducible (M) (D) 'Y'
Testing Impact (M)
Module / Page
Environment
Defect Summary (M)
Defect Description (M)
Comments
Attachments

Hope this will help a little.

Cheers,

-jerry-

Wishing you all a Blessed Christmas

2007-12-20T03:15:00.001-08:00

With Love

-jerry-

AST's Official Magazine December Edition

2007-12-18T04:43:00.000-08:00

Here we GO,

AST (Association for Software Testing) released their December 2007 Issue of Sapient Testing.
Another Good Work from them. Keep it up friends.

http://www.sapienttesting.com/files/December.Final.pdf

Cheers,
-jerry-

Instant Performance Test

2007-12-18T04:37:00.000-08:00

Hi All,

Like to do a instant performance test on your site with no cost. Here we go,
http://www.gomez.com/info_center/instant_test.php
try your site with this and get the instant performance details of it.

Thanks to sapienttesting and Scott Barber for his wonder ful work on December edition.

Cheers,
-jerry-

The 10 Commandments of Load Testing

2007-12-12T00:34:00.000-08:00

Here r the 10 Commandments of Load Testing.

Thou shalt know how thy test tool works.
Thou shalt gather realistic usage data.
Thou shalt have testable requirements.
Thou shalt write a test plan.
Thou shalt test for the worst case.
Thou shalt monitor your test environment infrastructure.
Thou shalt enforce change control on your environment.
Thou shalt use a defect tracking tool.
Thou shalt rule out thy own errors before raising a defect.
Thou shalt pass on your knowledge.

Visit http://www.myloadtest.com/ten-commandments-of-load-testing/ for full details.

Thanks to Stuart Moncrieff for his wonderful blog and his great service to Our Community.

Don't forget to visit his http://www.mypentest.com/ - security testing blog

and http://www.myloadtest.com/ - load testing blog.

Cheers,

-jerry-

Automation Testing Framework for Distributed Systems

2007-12-12T00:27:00.000-08:00

BizUnit
The adoption of an automated testing strategy is fundamental in reducing the risk associated with software development projects, it is key to ensuring that you deliver high quality software. Often, the overhead associated with developing automated tests is seen as excessive and a reason to not adopt automated testing.

BizUnit is a framework and as such does not have any dependency on either NUnit of VS Unit Testing, either of these make a great way to drive BizUnit test cases, though equally you could write custom code to do the same.

For further Details Vist :http://www.codeplex.com/bizunit
Thanks to kevinsmi for his great work.

Cheers,
-jerry-

Mother of all checklist for Software testing

2007-12-12T00:10:00.000-08:00

Hi All,
Here is the Mother of All Check List for software testing.
Hope this will be very helpful for most of our testing.
http://www.sqaforums.com/download.php?Number=437212
or
http://www.4shared.com/file/31856547/84194eaf/Mother_of_All_CheckListdoc.html

Thanks to Shreya for his wonderful work.

Cheers,
-jerry-

Project Testing Folder Structure

2007-12-05T03:19:00.000-08:00

Here is a good Testing Folder Structure. (just a sample)

Cheers,

-Jerry-

Entry and Exit criteria discussion in a Forum - ofcourse me too..

2007-12-05T03:07:00.000-08:00

More_Enjoy--
I am testing an web application. Any one can tell me what will be the entry and exist criteria for it.

Joe--
Entry Criteria : A set of decision-making guidelines used to determining whether a system under test is ready to move into, or enter, a particular phase of testing. Entry criteria tend to become more rigorous as the test phases progress. [R. Black]
Exit Criteria : A set of decision-making guidelines used to determining whether a system under test is ready to exit a particular phase of testing. When exit criteria are met, either the system under test moves on to the next test phase or the test project is considered complete. Exit criteria tend to become more rigorous as the test phases progress. [R. Black]

Jerryrajan (Me)--
Here comes the biggest problem of Software Testing. In my view specific definitions will not work for these cases. Because most of the people understand the testing terms in their own way and the very important thing is either they r in the right path or not.In my view the Entry Criteria is a collection of conditions / Objects that are very important to start testing; with out that if you start your testing that will be a failure.Exit Criteria is also collection of conditions / Objects that decides whether you can stop the testing or not.

Richard--
Which part of the definitions that Joe posted do not fulfill what you are saying? As I read them they match up.

Jerryrajan (Me)--
That is my own view Richard, not specifically for Joe.In simple words, "A set of decision-making guidelines" if someone got all guidelines and no resource to follow that.What are the entry criteria?If you r going to prepare a tour plan for your family using your car. What are the entry criteria?You, car, family, then the set of guidelines...correct me if I'm wrong.

Richard--
The guidelines will be specific per project, so the guidelines for deciding if you are going on your road trip would be: - Has the design documents been completed? (Tour plan written)- Are the resources available? (Car, people, luggage, holiday booked) If you can say yes, then you can decided to go live (go on the trip) So the entry criteria and exit criteria should include everything you need to go to the next stage of development, not some of it.

Jerryrajan (Me)--
Agreed.

Portable code editors

2007-11-28T03:48:00.000-08:00

As a Test Analyst, one must aware of the code behaviour. To work with codes occasionally some portable code editors are necessary. Here r two good code editors.
Notepad++ supports lot of languages.
VBS edit supports VB Script only. (specifically useful for QTP scripting)

Both are unregistered versions, (freeware anyway) and also portable.
So extract them and run it. (No installation required)
Pls purchase them if you feel they are useful.

http://www.4shared.com/file/30592543/d30fe88a/Notepad_Portable.html
http://www.4shared.com/file/30592566/91537e87/vbsedit_Portable.html

Cheers,
-Jerry-

Real-time HTML Editor

2007-11-28T01:54:00.000-08:00

Here is a Real-time HTML Editor.
If you r working with the Web Application and like to view your developer's code in other HTML editor and like to locate some defects.
Just copy their page source and paste in the Real-time HTML Editor. It will show you the page of your script.

http://htmledit.squarefree.com/

Cheers
-jerry-

Package Execution Status Sheet

2007-11-27T23:08:00.000-08:00

Here is a Package Execution Status Sheet for use cases or test cases.
This supports different cycles and different modules.
The sheet is fully automated.
Type your project name in the "Main Sheet", it will be updated in sub sheets.
Update the data in sub -cycle sheets, the status will get calculated in Main Sheet.

http://www.4shared.com/file/30577726/7e5521be/Package_Execution_Status_123.html

Post your comments to improve the sheet.

Cheers,
-Jerry-

Here is the comments and discussions on my previous question in a famous qa forum

2007-11-27T00:46:00.000-08:00

Jerry-
At last a Software Test Analyst's effectiveness is just based on his number of Defects….? This may looks funny, but is the Truth. In a project a Software tester's effectiveness is just measured (at last...) by his number of defects.This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...Pls post your comments.

Muthu-
Hi Rajan,I would recommend retaining Member B since your going to start with Execution Cycle. Test Case updating would be minimal during this stage.As a Test Manager we would need a Resource with good Logical and Analytical Skills to find more Valid Defects.

Richard-
Member B does sound like the logical choice, however the Test Manager must ensure that they do not lose any domain knowledge that can not be gained elsewhere. So they need to check that any information member A has can also be gained from other team members or get them to document it.

Jerry-
Thanks Muthu and Richard,Both views sounds good.If he released Member A: 1. The team manager will lose a domain knowledge Resource.2. No one is equivalent and accurate like executing his own test cases. (Hope we all experienced when executing other's cases)3. In India we use a term "Karuveapili" (the ingredient we add in food for good flavour, once cooked we throw it away)the Member A must not treated in such a way. The manager has to give him some acknowledge to that member and retain him in the project.4.I personally know that even Member B find some good critical logical defect apart from Use Cases he used to consult and clarify that defect with Member A.(I'm very confused)

Richard-
Sounds like there is not going to be an answer that is perfect, the project is going to lose out some way, and somebody is going to be upset. (assuming that they are not leaving the company I would do the below)I would explain to member A that he has to lose one person. Make it clear that they have done tremendous work on the project, and the project would not be in such a good state going into the testing phase without them, however he is letting them go as they are much more valued for their test case planning and use case reviewing (etc etc) and therefore will be more value to another project in that capacity. To member B I would explain that the have been kept on due to their excellent eye for detail and finding really good incidents. However as member A is moving on to other projects this is a really good opportunity for them to grow in their role and take responsibility and ownership of the issues and have the confidence to speak to developers/designers etc to clarify issues. Hopefully this will mean member A understands that they are not Karuveapili (love that phase, thanks!) and member B can grow in their role and it will effect the project in a good way. Does that help?

Jerry-
Wow Man Richard,Really wonderful decision. I'm feeling very happy on reading this reply. (Small fish with big humanity and human administration...!)Many Thanks for your effort.

Joe-
I completely disagree.Defect count by itself is a poor measure of effectiveness.Consider...Tester 1 finds 100 defects. All of them are surface-level defects in code that has many, many defects present. And, the existing critical defects have been completely missed.Tester 2 finds 10 defects. All of them are critical, and there are no other critical-level defects remaining in the code.I know which of the two I would choose.

Jerry-
Yes Joe, you r right.In your situation, Every one will give First priority to the Tester 2 and Second priority to Tester 1.(Anyway a defect is a defect is a defect, doesn't matter big or small)But here the case is different. Either you keep the one good in finding defects or the one good in Domain Knowledge and talented in Test Design.

Hope you all enjoyed.
-Jerry

At last a Software Test Analyst's effectiveness is just based on his number of Defects….?

2007-11-22T21:56:00.000-08:00

This may looks funny, but is the Truth. In a project a Software tester's effectiveness is just measured (at last...) by his number of defects.

This happened in my nearby project. The team has to release a resource according to the plan and the team manager is breaking his head to make a decision. At last he got two names to select one. Member A is very good in overall application knowledge and designing test cases. Member B is very good in finding defects (even apart from TC execution), with lot of sense and logical aptitude. Now almost the TC design stage is over and they are in the execution stage. What the Team Manager do, whom will he release...

Pls post your comments.

A good function to get ur o/p in XLS

2007-11-21T22:06:00.000-08:00

Here is a good function in VBS to generate your application output in XLS.

Function create_excel ()

Dim xl, St
Set xl = CreateObject("Excel.Application")
xl.Workbooks.Open "C:\Project-Main\Project-Sub\Output.xls"
Set St = xl.ActiveWorkBook.Worksheets("Global")
St.Cells(2,13) = "123"
xl.ActiveWorkbook.Save
xl.ActiveWorkbook.Close
xl.Application.Quit

End Function

This function will export the data from the Global sheet to Output.xls

-jerry (Thanks to RD)

Security Testing Publication

2007-11-20T03:59:00.001-08:00

Here is a very good publication on security testing by
Computer Security Division, National institute of Standards and Tech of USA.
May be the old one, but very intresting and usefull.

http://csrc.nist.gov/publications/nistpubs/800-42/NIST-SP800-42.pdf

Cheers,
-Jerry-

SOA Testing

2007-11-15T04:01:00.000-08:00

SOA (Service-oriented architecture) is a very hot topic now in market. SOA Testing is hottest then automation. Visit this site to update ur knowledge in SOA.

The Blog is all about SOA Testing techniques used for testing IT assets that are part of a Service Oriented Architecture. As SOA begins to tie the fabric of IT infrastructure, actively and aggressively testing Web Services has become crucial. Comprehensive Functional, Performance, Interoperability and Vulnerability Testing form the Pillars of SOA Testing. Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.

http://soa-testing.blogspot.com/
Thanks to Mamoon Yunus for his good work.. Go on Friend.

25 Photographs Taken at the Exact Right Time

2007-11-15T01:11:00.000-08:00

Wow, this is not any photographic gimmick. Just true snaps with ultra fast frame shot.

Want to look all. Visit the site...http://sawse.com/2007/11/02/25-photographs-taken-at-the-exact-right-time/

Another good Estimation article

2007-11-13T05:13:00.000-08:00

Here is another Good Estimation Article...
Thanks to Paul for this.

Why are our estimates always too low?

At last week's Test Management Forum, Susan Windsor introduced a lively session on estimation – from the top down. All good stuff. But during the discussion, I was reminded of a funny story (well I thought it was funny at the time).

Maybe twenty years ago (my memory isn’t as good as it used to be), I was working at a telecoms company as a development team leader. Around 7pm one evening, I was sat opposite my old friend Hugh. The office was quiet, we were the only people still there. He was tidying up some documentation, I was trying to get some stubborn bug fixed (I’m guessing here). Anyway. Along came the IT director. He was going home and he paused at our desks to say hello, how’s it going etc.

Hugh gave him a brief review of progress and said in closing, “we go live a week on Friday – two weeks early”. Our IT director was pleased but then highly perplexed. His response was, “this project is seriously ahead of schedule”. Off he went scratching his head. As the lift doors closed, Hugh and I burst out laughing. This situation had never arisen before. What a problem to dump on him! How would he deal with this challenge? What could he possibly tell the business? It could be the end of his career! Delivering early? Unheard of!

It’s a true story, honestly. But what it also reminded me of was that if estimation is an approximate process, our errors in estimation in the long run (over or under estimation) expressed as a percentage under or over, should balance statistically around a mean value of zero, and that mean would represent the average actual time or cost it took for our projects to deliver.

Statistically, if we are dealing with a project that is delayed (or advanced!) by unpredictable, unplanned events, we should be overestimating as much as we under estimate, shouldn’t we? But clearly this isn’t the case. Overestimation, and delivering early is a situation so rare, it’s almost unheard of. Why is this? Here's a stab at a few reasons why we consistently 'underestimate'.

First, (and possibly foremost) is we don't underestiate at all. Our estimates are reasonably accurate, but consistently we get squeezed to fit with pre-defined timescales or budgets. We ask for six people for eight weeks, but we get four people for four weeks. How does this happen? If we've been honest in our estimates, surely we should negotiate a scope reduction if our bid for resources or time is rejected? Whether we descope a selection of tests or not, when the time comes to deliver, our testing is unfinished. Of course, go live is a bumpy period - production is where the remaining bugs are encountered and fixed in a desperate phase of recovery. To achieve a reasonable level of stability takes as long as we predicted. We just delivered too early.

Secondly, we are forced to estimate optimistically. Breakthroughs, which are few and far between are assumed to be certainties. Of course, the last project, which was so troublesome, was an anomaly and it will always be better next time. Of course, this is nonsense. One definition of madness is to expect a different outcome from the same situation and inputs.

Thirdly, our estimates are irrelevant. Unless the project can deliver in some mysterious predetermined time and cost contraints, it won't happen at all. Where the vested interests of individuals dominate, it could conceivably be better for a supplier to overcommit, and live with a loss-making, troublesome post-go live situation. In the same vein, the customer may actually decide to proceed with a no-hoper project because certain individuals' reputation, credibility and perhaps jobs depend on the go live dates. Remarkable as it may seem, individuals within customer and supplier companies may actually collude to stage a doomed project that doesn't benefit the customer and loses the supplier money. Just call me cynical.

Assuming project teams aren't actually incompetent, it's reasonable to assume that project execution is never 'wrong' - execution just takes as long as it takes. There are only errors in estimation. Unfortunately, estimators are suppressed, overruled, pressured into aligning their activities with imposed budgets and timescales, and they appear to have been wrong.

Visit his site...

http://uktmf.com/blog/paulgerrard/2007/05/why_are_our_estimates_always_t.html

A good magazine for testing

2007-11-12T21:47:00.000-08:00

Here is a good magazine for software testing.
http://www.stpmag.com/

Cheers,
-jerry

Wanna update yourself....

2007-11-12T21:44:00.000-08:00

Ya, if you want to update yourself in testing (black or white). Visit the new Microsoft's Test Blog.
http://msdn2.microsoft.com/en-us/testing/default.aspx
you can find great articles here soon...

Equivalence class partitioning By Testy

2007-11-12T21:43:00.000-08:00

Equivalence class partitioning (ECP) is a functional testing technique useful in either black box or white box test design. A technique is a systematic approach to help solve a complex problem. Techniques are not silver-bullets, but they are a logical and analytical approach to problem solving that heavily draws upon the tester's cognitive abilities (having a basis in or reducible to empirical factual knowledge) as opposed to random guessing (or little men running about inside one's head triggering turbid thoughts). Contrary to popular misconceptions the application of ECP is not a rote, brain-dead activity. The ECP technique requires in-depth knowledge of the data set (data type, encoding method, etc), the programming language used in the implementation, the algorithm structure, the operating environment, protocols, and even the hardware platform may impact how the data for a particular parameter might be decomposed. The effectiveness of the application of this technique solely lies in the testers ability to adequately decompose the data set for a given parameter into subsets in which any element from a specific subset would produce the same result as any other element from that subset.

To View the full article visit..http://blogs.msdn.com/imtesty/archive/2007/10/31/equivalence-class-partitioning-part-1.aspx

Thanks to Mr. Testy for his wonderful work.

Here r few funny Testing related cartoons.

2007-11-12T04:33:00.000-08:00

Thanks to Leo Rex for this pictures...

Cross-browser compatibility

2007-11-06T01:02:00.000-08:00

For All Web Application Browser compatibility test is very essential. If you look at the picture above here about the usability of different browsers worldwide. Then we can understand the percentage of compatibility test we must try with different browsers.

For further Detail about the Cross-browser compatibility test Visit

http://www.smashingmagazine.com/2007/10/02/browser-tests-services-and-compatibility-test-suites/

-Good Day

Generate Data - the test data generator

2007-11-05T00:35:00.001-08:00

Today i found an Test Data Generator. http://www.generatedata.com/#generator
This really rocks. May be simple but works fine. Forgive them if you find some page errors in between.

Ofcourse free but if you want donate them something.

QA Time Estimation based on Dev's Time Estimation

2007-10-29T22:43:00.000-07:00

Actually for QA Time Estimation we have to work and calculate a lot with lot of things like the previous post says. But that all things will never available in real life. If Project Manager asked for QA Time Estimation without any statistical data but just with Development time estimation, then we can follow the "general rule of thumb" that is 2/3 of the development estimate.

Remember, this will not be very accurate. But truthfully nothing is accurate in estimation, even for satellite lunching they may not have accurate plane.

In case dev estimated 66 days and for QA you can suggest 48 days, hopefully that won't cross then that. (4 days for backup). But still this estimation is just a lollypop to show not the real cake to eat…!!

Software Testing Cycle Diagram

2007-10-29T06:50:00.000-07:00

Here is an good software testing diagram from research.ibm

Estimating Testing Projects

2007-10-29T04:25:00.000-07:00

Hi All, today i found a good article on "Estimating Testing Projects"
This is really easy and good to understand ...
here is this for u all...

Estimating Testing Projects
Walkthrough on How-To
The online content i have found regarding developing sound estimations for testing projects are found to be wanting in a lot of ways

# Articles start of promising and end up with “Software project estimation - Seat of the pants approach”.
# Articles packed with a lot of know-know but absolutely no how-to
# Articles that tell me how to keep doing what we are already doing.

Current Affairs

The current situation of software project estimation can be best described as CMM level 1 heroics. The nearest we conventionally come to it is a WAG (Wild Ass Guess). As to how this has become an acceptable practice in the software industry defies my comprehension!!?$!?!^@?!!! Sometimes people even go to the extent of categorizing this “exercise in futility” as a SWAG( Scientific Wild Ass Guess).

Bottomline: Doing a WAG or SWAG (Whatever you call it) is as good as doing no estimation at all.

What is an estimate?

An estimate serves as a masterplan for a software project covering all aspects like costing,staffing,timing. Hence basing this on pure guess work is a definite NO

Ok history apart lets get started……

Since this is a walkthrough on how to do an estimate we will start from scratch and move to the end…..Please note that there are a lot of conventional things that we do which can remain as is. Lets concentrate on the flaws that haunt the practice.

1. Collectibles to start an estimate

Starting an estimation is back breaking work . There are the following elusive documents that one has to procure before sitting down to a sensible estimate.

1. Customer Requirements Specification

2. Request for proposal,

3. System specification/ Architecture.

4. Software Requirements Specification

I have often hear the following complaint, “Owwww but these don,t exist at that point”. The reply to that is that as per SDLC (Waterfall, Iterative, Jumbo circus whatever) models of software development these are the primary documents that need to be in place before we estimate for a project.The necessity of having these document in hand is to prevent the wild ass from guessing about our project

2. Approaches to preparing QA estimates for a project

There are a lot of sound practices that people have been using to prepare development estimates like system lines of code (SLOC), use-case based analysis, function point analysis, object hierarchy trees etc.In the following section i have proposed some of the techniques that can be used to prepare QA estimates for projects.

1. Begin estimation by conducting a comprehensive study of the system architecture, scope of work and the analyzing the complexity of work.

2. Determine what style of testing should be used in the strategy (you could chose from many options like use case based testing, scenario based testing, module hierarchy trees to name a few). This is a very important step which most QA personnel skip.

3. If you are adopting a module based testing, prepare a module hierarchy tree to visualize the inter-dependencies between modules.

4. Analyze and assign complexity to each node of this tree. Estimate the number of test cases in each module by analyzing the # of functionalities bundled in each module.

5. Ascertain by past experience or analysis, a realistic projection of QA productivity (no of test cases per person day). This is a metric which varies and WILL NOT FOLLOW ANY PRE-DEFINED ORGANIZATIONAL NORM.

6. Analyze each module to arrive at a preliminary idea of the extent of automation that is possible in each of these modules.

7. Estimate the strategy of automation in terms of how you will automate the testing, what will be the coverage of automation, what will be the complexity of developing automation scripts if any. ( a POC might be required for this at a later stage. This has to go into the estimate. Doing POC’s for software test automation is a severly neglected critical component of delivering QA processes.)

The above 7 steps have to necessarily completed and documented before you can start with the estimate.

3. Preparing the estimate

Identify the risks involved. These can range from technology risks, risks introduced by the delivery model that has been adopted and many other factors. Each risk identified has the potential of throwing your estimate haywire. Hence de-risking the project is an important part of estimation. In situation where the number of risks identified are high, it would be a good practice to prepare 2 separate estimates

# Conservative estimate: This will factor all the overruns in terms of effort, time and cost that would transpire if the risks realize themselves.
# Optimistic estimate: This will envision the delivery of the project if the risks identified do not materialize.

The benefit of having 2 versions of the estimate is that it would provide a clear cut picture of how bad things can go when risks materialize and what would be the losses incurred if the are let to remain.Conservative estimates can be projectional in nature where the increase in time, effort and cost can be show as a projection in relation to the risk.

The process of preparing the estimate start only once the above steps have been completed. All factors in the estimate have to be traceable to the documentation that has been prepared as part of section 2 of this document. The actual process of doing the estimate like assigning timelines and resource loading will be guided by the above section and help you arrive at a sound estimate.

The Golden rule of all estimations “DO NOT DO SOFTWARE PROJECT ESTIMATIONS WITHOUT ALL NECESSARY SUPPORT DOCUMENTATION IN PLACE.”

I have outlined only the measures to curb the flawed practices in the estimates. These could be incorporated to modify the existing process(if any) of preparing estimates within your organization. A complete walkthrough would expand the scope of this article exponentially

Thankfully From : http://www.testinglounge.com/2007/06/12/qa-estimation/

By :Robin Thomas

Testing Measurement - a nice high leval article

2007-10-24T01:15:00.001-07:00

Someone has rightly said that if something cannot be measured, it can not be managed or improved. There is immense value in measurement, but you should always make sure that you get some value out of any measurement that you are doing. You should be able to answer the following questions:

# What is the purpose of this measurement program?
# What data items you are collecting and how you are reporting it?
# What is the correlation between the data and conclusion?

Value addition
Any measurement program can be divided into two parts. The first part is to collect data, and the second is to prepare metrics/chart and analyse them to get the valuable insight which might help in decision making. Information collected during any measurement program can help in:

#Finding the relation between data points,
#Correlating cause and effect,
#Input for future planning.

Normally, any metric program involves certain steps which are repeated over a period of time. It starts with identifying what to measure. After the purpose is known, data can be collected and converted in to the metrics. Based on the analysis of these metrics appropriate action can be taken, and if necessary metrics can be refined and measurement goals can be adjusted for the better.

Data presented by testing team, together with their opinion, normally decides whether a product will go into market or not. So it becomes very important for test teams to present data and opinion in such a way that data looks meaningful to everyone, and decision can be taken based on the data presented.

Every testing projects should be measured for its schedule and the quality requirement for its release. There are lots of charts and metrics that we can use to track progress and measure the quality requirements of the release. We will discuss here some of the charts and the value addition that they bring to our product.

# Defect Finding Rate
This chart gives information on how many defects are found across a given period. This can be tracked on a daily or weekly basis.

#Defect Fixing Rate
This chart gives information on how many defects are being fixed on a daily/weekly basis.

#Defect distribution across components
This chart gives information on how defects are distributed across various components of the system.

# Defect cause distribution chart
This chart given information on the cause of defects.

# Closed defect distribution
This chart gives information on how defects with closed status are distributed.

# Test case execution

# Traceability Matrics

# Functional Coverage

# Platform Matrics

-----------------With thanks from http://testinggeek.com/
Cheers,
-jerry

Browser Tests, Services and Compatibility Test Suites

2007-10-24T01:01:00.000-07:00

Here is an wonderful article about browser compatibility and cross browser testin for web application.

Worth visiting...

http://www.smashingmagazine.com/2007/10/02/browser-tests-services-and-compatibility-test-suites/

Cheers,
-Jerry

Better Folder Structure

2007-10-23T03:14:00.000-07:00

Here is an better folder structure for an project drive.

Cheers,
-jerry

A wonderful GUI Checklist from Rathish

2007-10-22T05:35:00.000-07:00

Description
All screens should include blue face and white borders
Look and feel of all buttons should be fixed according to windows buttons
“Century” application selected by default on all screens
Hyperlink on century logo, help, sign out
Refreshing the page
Hyperlink on welcome user information
Links to the two tabs-User management, Reports
On mouse over of the tab drop down should occur
Equal borders on the right pane
Alignment of the Frame
Equal spacing between search tab and table header
Color consistency between left margin and table header
Color gradient on the frame
Font consistency
Representation of hierarchy with folders
Change of icon in the tree
Checking for GIF
Vertical scroll bar on the left pane
No scrolls on right pane
Scroll bars should be as XP color
Frame consistency in showing the details
Selection of links on mouse over
Link reflection (tree expansion)
Visited link color
Unvisited link color
Links on tree list allows the user to traverse to the particular page
Navigation link with records on all screens
10 records are listed in a page
Display of total number of records at the bottom of the page
No display of records on empty listing page
“First” and “Prev” is disabled if the user is on the first page
“Next” and “Last” is disabled if the user is on the last page
Basic search tab enabled by default
Criteria combo enabled on loading
Condition combo disabled on loading
Size of the combo
“Add Condition” with hyperlink on advanced search tab
In advanced search, “match any” selected by default
Delete button is added for each row newly inserted in advanced search
No text box for “assign to” search option
All icons are placed at top right corner
All icons should be vertically centered
Pop up messages for all icons
Check for button name
Hyperlink on tabs with user privilege
Search tab visibility based on privileges
Title - population of hierarchy
Equal spacing between Assign to, Start and Target date
Check box on the table header
Hyperlinks on each hierarchy listing
All listing screens are read only
Check box for all records listed
Proper alignment of text in the listing page
All records listed in alternative color
Display of description value with tool tips
Eclipse is appended for values whose length is greater than the specified value
Text area should have hairline border
Gray scroll bar in the description
Tool tip range
Tool tip on mouse over
Display of dates in dd-mon-yy format on all listing screens
Focus set on specific fields - on loading
Calendar popup
Text box for display of dates is read only
Space consistency between description field and buttons while creating hierarchy
Hyperlink on buttons on creation and edition of hierarchy
Inner borders for create / edit hierarchy
Success / confirmation messages
Alert / failure messages
Lowercase, upper case and check for sentences in all messages
After message no tab key functionality should be allowed
Attachment symbol on the header
Attachment symbol inclusion for each test case
Attachment symbol width consistency
Assign and deassign buttons are placed next to target date field
No link to view tab
Links on the test cases allows the user to move to view tab
All the fields in view tab are non editable
Order transaction type selected by default
Color consistency between attachment button sub menus and screen controls
Hyperlink on attachment tab
Attachment tab with table structure
Check box on attachment table
Hyper link on all buttons at the bottom of the attachment tab
Reset to clear values
Moving back and forth in explorer window
Back button to traverse
All screens under user management should have frame borders
All loading screens should be frame centered
Double borders not allowed in privileges
Application name can be darker in assign privileges
“Assign to” combo is not present in project and cycle management
Table headers should have 5 pixel spacing
Hyperlink on the value in the attachment type
Listing tabs are enabled always
Adjustable divider is required
Navigation as link as blue/underline non-link gray
Movement of the screen (Click and drag)
Horizontal line in the message window
Text Alignments
Window Alignment/positioning
Attachment file - size constrain

Here r Team SST - MM photos-enjoy

2007-10-22T01:37:00.001-07:00

Planed to post an article on SST-MM soon..

Cheers,

-jerry and Team SST

30 Usability Issues to be aware of

2007-10-19T01:23:00.000-07:00

Today i found a wonderful article about usability issues of web.
Hope this will be very helpful in designing a good web page and in testing too...

http://www.smashingmagazine.com/2007/10/09/30-usability-issues-to-be-aware-of/

The next one is about the same usability in web but some nightmares to come out from

http://www.smashingmagazine.com/2007/09/27/10-usability-nightmares-you-should-be-aware-of/

Cheers,
-jerry

The final question to KAREN N. JOHNSON by QA Zone

2007-10-12T00:56:00.000-07:00

Q8- Thank you very much for your time, Karen. Let’s end with a quick recommendation…For QAZone members that are looking to grow their team, what do you think are the most important skills or personality characteristics that they should be looking for in new team members during their hiring process?

KNJ- Curiosity, I can’t stress this enough!. Testers need to be curious people, constantly wondering things such as what if I do this, or what if fill-in-the-blank here. Technical skills can be taught if someone has the aptitude and motivation. But behind all good testers, there is a burning curiosity. I think this is why testers enjoy TV shows such as the CSI series. We like to solve mysteries, we like the investigations, the fact-finding and the details. Coincidentally I think having a curious mind keeps us young and engaged with life as well.

Five Important things to work with in before Test Plan

2007-10-12T00:48:00.000-07:00

Its so simple...
1. Your Project.
2. Your Resources.
3. Your Budget.
4. Time Available.

Keep all these things in your mind and prepare Test Plan.
Don't do test plan with a mind setup of satisfying ur customer or to do 100% testing.
That's not possible. So work with the possible things..

-jerry .. :-)

Good explanation on test-driven development

2007-10-05T01:31:00.000-07:00

There seems to be a lot of confusion and misinformation out there about what exactly we mean by test-driven development.

I sometimes use this little analogy to help explain it:When I moved in to my first house, me and my girlfriend of the time (who was a total cow, I should hasten to add - not that I'm bitter or anything) went shopping for kitchenware.
Our method was simply to sit down and draw up a list of "things that a kitchen should have" - like crockery, cutlery, mugs, glasses, scales, egg whisk, bowls, and so on.We spent hours in IKEA, British Home Stores and various other purveyors of culinary paraphernalia, and then we dragged everything back to the house and unpacked it into our new kitchen.
When we'd finished we sat at the breakfast bar with a cup of tea and surveyed our handiwork. It wasn't until the next day when I tried to make a mushroom omelette that I realised we'd forgotten to buy a frying pan. And when my girlfriend tried to make herself a Jack Daniels & Coke on ice that we realised we'd forgotten to buy any ice trays for the freezer. Or suitably sized glasses for a whiskey and coke, come to that. So I had cornflakes for breakfast, and and in the evening she enjoyed a warm whiskey and coke served in a small wine glass.

What we should have done, of course, was make a list of examples of things we'd be using our kitchen to do. And then figuring out what we'd need in our kitchen in order to successfully execute each of these scenarios.That way, I would have most certainly remembered the frying pan, and Sarah would have had a nice, cold drink our of a more appropriate glass.
TDD is specification by example. Each test case describes a way in which the end product will be used - whether that end product is a kitchen, a software applictaion, or just a single method in a single class in a software application. It's not really a testing discipline at all. It's a design discipline. I think maybe it's the "t" word that confuses people, though. Some teams write seven billion lines of code, and then write a handful of unit tests to cover it, and then come to me and say "we're doing test-driven development". No. Not if you write the tests after you've written the code, you're not. In TDD, tests drive development - the clue's in the name. You only write code needed to pass tests. So your tests are a specification for the code you need to write.

The fact that afterwards you end up with a suite of executable regression tests is a positive side effect of doing TDD. It is not the primary goal of TDD, though.
The primary goal of TDD is to use tests to drive the design and implementation of the software.And that, my fine feathered friends, is test-driven development.

-Thanks to Jason Gorman....wonderfully explained.. :-)

10 Software Development No-Brainers

2007-09-04T03:53:00.000-07:00

Here is a cool post by jason Gorman....

I spend a considerable amount of my life locked in meeting rooms listening to protracted discussions about stuff that I could have sworn we'd sorted out years ago.

I'm thinking maybe, to save time and heartache, I should make a list of these no-brainers and their screamingly obvious solutions so we can all get on and apply our feeble minds to more important problems - like where to get the cheapest liquor.

1. What should be our Coding Standards? - Google "coding standards" for your chosen programming language, find a set that makes sense to you and then use them.

2. Should we do iterative development? - No. You should stick your head up an elephant's arse instead. It has about the same effectiveness as waterfall delivery, but is slightly less unpleasant for the parties involved.

3. Model-View-Controller or Model-View-Presenter? - seriously, who gives a sh*t? Pick one and get on with it.

4. .NET or Java? - ditto.

5. Are we doing too much unit testing? - No.

6. Do we need a business/systems analyst? - nobody needs a business/systems analyst. They're like nipples for men - they serve no practical purpose, but they can still be used to hurt you.

7. Should we adopt a Service-Oriented Architecture? - Sure. Just let the rest of us know when you've figured out what the hell that means, okay?

8. Are we doing too much refactoring? - No.

9. The guy we want is just outside our budget. What do we do? - Increase your budget. Find a way.

10. How can we make more time for quality? - Just do it. The extra time will make itself.

--Thanks Jason...this is cool

How did we miss THAT?

2007-08-24T04:43:00.000-07:00

Here is another intresting blog i visited....

How did we miss THAT?
Filed under: Thinking Like a Tester, Ruminations — Elisabeth Hendrickson @ 11:12 am
“Oh goodness. How did I miss THAT bug?”
Over the years, I’ve asked myself that question numerous times.
I asked that question when another tester found a blazingly obvious, critical bug that I completely missed. (The answer: I spent too much time tinkering with an ineffective automated script I’d written, and too little time observing the actual behavior of the system. That’s the project where I learned a lot about how NOT to do test automation.)
I asked myself that question, repeatedly, when I participated on a project some years ago now where we shipped software that crashed left and right. (I’m still sorting out the answers to that last one. Catastrophic failures are almost never the result of a single, simple error. And this particular catastrophic failure represented failures at all levels in an organization that had, um, issues. But I digress.)
I asked the question again when I learned that a web site I tested had back-button problems. After all, I was sure I’d tested for that. And I had. But I hadn’t re-tested for it after a particular set of code changes that changed some operations from HTTP GETs to HTTP POSTs. Oops.
And I asked myself that question more recently when I learned that a system I worked on earlier this year failed to save a change, and also failed to report an error, when it encountered data misformatted in a particular way in one specific field. Badly formatted data is one of my specialties, and I couldn’t believe I forgot to test the particular case that resulted in the problem. But it turned out that I did, indeed, fail to test what would happen if you entered “www.testobsessed.com” into a URL field instead of “http://www.testobsessed.com”. In hindsight, it’s an obvious test. Another lesson learned.
I reflected on those missed bugs when a colleague, Sandeep, a test manager, recently wrote to say that he’s been asking himself “how did my testing team miss that?”
He decided to seek out patterns of testing problems by categorizing escaped bugs according to the hole(s) in testing that allowed the bug to slip through. The idea is to improve the test effort by figuring out the common causes behind escaped bugs.
My initial reaction was, “that makes sense.” If you can identify the top 20% of testing holes that let 80% of the bugs through, and you can make some serious improvements to the test effort.
And my next reaction was, “but be careful.” Sandeep’s intent is good: use lessons learned from escaped bugs to improve testing. However, asking “How did we miss that?” is perilously close to heading down the slippery slope to “How did JoeBob miss that?” to “It’s JoeBob’s fault.” Having talked to Sandeep, I know he’s not trying to play “pin the blame on the tester.”
So I suggested a small reframe.
Instead of categorizing escaped bugs by asking the question, “How did testing miss that?”, categorize them by asking the question, “How can we improve the probability that testing will find bugs like that in the future?”
It’s a subtle difference.
But the result of reframing the question is that instead of identifying categories as noun phrases like “insufficient test data,” we end up with imperative statements like, “add test data.” Those two categories may look almost identical, but only one is actionable. I can “add test data.” The statement prompts me to do something different next time. But “insufficient test data” only gives me something to regret. And regret won’t help me ship better software.
So how can you categorize escaped bugs to improve the test effort without falling into the blaming trap? Try an Affinity Exercise with the question, “What could we do differently next time to increase the probability that if we have another bug like this we’ll catch it in test?”
To prepare:
Choose a team to participate in the activity. Affinity exercises can work with any number of people, but for this particular activity, I find a smaller group - say 3 to 5 people - works best. It’s a good idea to include people with diverse roles and skill sets.
Set up a meeting time and place. Plan for the whole activity to take 2 hours. And arrange to meet in a place with plenty of table and/or wall space.
Gather (or shop for) office supplies. You’ll need:
Index cards or sticky notes. Bigger is better. I like 5×8 cards or the SuperSticky 5×8 Post Its.
Felt-tip markers. I like Sharpies because they make consistently dark, readable marks. (Beware: Sharpies are permanent. Do NOT confuse your Sharpies and your White Board markers in the conference rooms. Facilities people get tetchy about such mix-ups.)
Gather a list of escaped bugs you want to analyze. If you have a lot of escaped bugs, prioritize them and time box the exercise. (You probably won’t be able to analyze more than 50 in an hour, possibly less, so don’t print out a list of 500.)
In the Meeting:
Review each bug with the team, asking: “What could we do differently next time to increase the probability that if we have another bug like this we’ll catch it in test?”
Have participants write their suggestions on the cards/stickies, one idea per card, in the form of an actionable statement. The suggestions should complete the sentence, “In the next release/iteration/sprint, we can ______.” Tips:
Also ask the participants to make their suggestions as concrete and specific as possible. For example, instead of writing “add test data,” write “add titles with ampersands (&) to the test data.”
And ask the participants to stick to test-related actions, and avoid blaming individuals. “Revoke NancySue’s checkin priviledges” is not an acceptable suggestion.
When you’ve reviewed all the bugs, or when an hour has passed, stop reviewing bugs. (If you still have lots of bugs to go and want to continue analyzing after an hour, stop anyway. Finish the rest of the exercise - the grouping. When you’ve worked through the whole process, if you still think more analysis would help, you can always do the exercise again.)
Gather all the cards/stickies, and lay them out on a large work surface: a table, the walls, or even the floor can all work well.
Sort through the cards/stickies as a team. The cards are now owned by the team, and everyone should take a hand in organizing them. Encourage participants to move cards that seem alike together so they are stacked together. Continue until the team agrees that it’s satisfied with the stacks of cards/stickies.
Ask the team to give meaningful names to the stacks of cards/stickies. This is the part of the activity where will generate the more abstract categories like “add test data.”
The result of this exercise is a list of categories for improving the testing effort that we can then use to determine which kinds of improvements will have the biggest bang for the buck. And the best part is that the list emerged from the actual problems your software has had in the field rather than being some arbitrary list of theoretical “improvements” based on someone else’s unrelated experience.
But wait; you’re not done. Now that you’ve created a first draft list of categories, test it. (Did I mention I’m Test Obsessed?) Choose a different set of escaped bugs, and assign each to one or more categories from the list. Notice how easy or hard it seems to find a category for each bug. This will give you a lot of feedback about how well the category list will work in practice. You may find the team needs to spend some additional time iterating on the list.
Once you’re satisfied with your list of categories, you can run the numbers to see how many bugs are in each category. Then you can create a Pareto diagram of the results to see what 20% of the improvement opportunities on your list will result in an 80% improvement. Now you can truly leverage escaped bug information into concrete actions that will make the test effort more effective.
Over time, as you try to use that original list to categorize reports of new bugs in the field, you will probably find that the list becomes less and less relevant. I hope so, anyway. It indicates that the improvement efforts are working, that the team has improved the test effort.
That’s when you know it’s time to do the process all over again to classify the next generation of escaped bugs.

Ten Worst Software Bugs

2007-08-20T03:28:00.000-07:00

Before going into the worst bugs, do you know why computer program errors are called “bugs” and why developers like myself “debug” programs? It all goes back to September, 1945. Here is the story:
Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1945. The operators affixed the moth to the computer log, with the entry: “First actual case of bug being found”. They put out the word that they had “debugged” the machine, thus introducing the term “debugging a computer program”.

Here is the log, with the moth still taped by the entry:
source

Now on to the worst moths… Oops, I mean bugs. Wired News published an article about history’s worst software bugs. Here is a summary of the 10 worst software bugs in chronological order:
1962 — Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch.
1982 — Soviet gas pipeline. Operatives working for the CIA allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The resulting event is reportedly the largest non-nuclear explosion in the planet’s history.
1985-1987 — Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities.
1988-1996 — Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly “seed” the program’s random number generator with a truly random seed.
1990 — AT&T Network Outage. A bug in a new release of the software that controls AT&T’s #4ESS long distance switches causes these mammoth computers to crash.
1993 — Intel Pentium floating point divide. A silicon error causes Intel’s highly promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range.
1995-1996 — The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed “ping” packet from anywhere on the internet.
1996 — Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5’s faster engines trigger a bug in an arithmetic routine inside the rocket’s flight computer.
2000 — National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.

I noticed that “Y2K” did not make the list. I guess because it was not the worst or it was not a bug, or is it?

---Thanks to awards.net

A wonderful learning experience on testing

2007-08-17T03:12:00.000-07:00

A true story about learning about software testing… a long while ago I had a boss named Bob. At the time I was fairly new to software testing. Bob had knowledge on many topics. He had an approachable way about him that made working with him and for him one of my most positive experiences in my life. I realize now the primary reasons for this: I love to learn and enjoy the role of the student. Bob was a great teacher by nature. Together for a long stretch we made a great pair.I use to ask Bob time and time again, what should I learn now? He would sit back at his desk and think about this. Then he would take a book from his bookshelf. Sometimes he would suggest reading a whole book and sometimes just a section. The concept of not reading a book front to back like a novel gave me permission to take what I wanted and leave the rest. He’d answer in ways like this: learn a little more SQL, learn more about data types, or go look read more about user interface standards. Sometimes depth, sometimes breadth. But here’s one point. he knew me. He knew what I knew, he knew pretty well what I didn’t know and he knew clearly what my work objectives and challenges were – and sometimes he would ask me, what are your current frustrations or stopping points? This made my asking Bob a good question because he had a frame of reference. This is an important point – sometimes people email me this same question, so please consider that I’m going to be limited in how I answer the question because I don’t know you and I don’t know your background. And I don’t know what you might be trying to accomplish. But you do.I remember one day after working with him for years, I asked the same age old question. Bob, what should I learn? He looked up at his bookshelf turned to me and said; it may be time for you to teach. I was actually sad that day; I wanted to remain the student. But with a deep sigh, I accepted that it might be time to pass on some knowledge and that it was also time for me to continue on my own.I had resolve this continuing question for myself. I think I learned a bit or more about learning from Bob. I look for my educational gaps. I know where they are. I have a mix of topics that interest me, topics I feel/know I need to learn more and sometimes topics I need learn to resolve new technical challenges at work. Sometimes I catch up on pure software testing materials from the work of other people in the field.Bob hasn’t been my boss for a decade or more now. But I was fortunate to have had the time with him. Years later, I find myself hiring testers. I share every book I own. I highlight sections, I point out websites. I suppose, the cycle repeats. It feels good to help other people. Though a large part of me I suspect remains a grasshopper.

-Thanks Karen N. Johnson for sharing the great time with ur teacher.

Intelligent search engine?

2007-08-10T04:51:00.000-07:00

Today I searched the basic functions of the project I'm working with, and performed some search options available with. The application used to perform some default search if we not specified (default specification is there) anything. I removed all the default search input and performed the search. (Without any input) But it result me the same default search. Actually I expected some error message to insist the end user to give some input (intelligent programming…:-). But it was not. (it has a special specification to result everything in the DB)

Then I did an empty search test in some famous search engines. Just open some search engines, without entering any search key perform the search. Aaha it all returns to its original page. This happened to most of the search engine like Google, yahoo, AltaVista, etc.

What I expect in the search engine is this.

The search engine may result some message (error) to the user to enter some input or at least it may lead to the web search help page.
The search engine may provide some search result about the empty space (preferably white space or blank space).

I really don’t know what is right on this case. Anyone want to comment about this…pls shoot.

The Web Testing CheckList

2007-08-10T01:34:00.000-07:00

The Checklist
The links in the checklist lead to a discussion of each issue.

Validation
Validate the HTML
Validate the CSS
Check for broken links
Flexibility
Try varying window sizes
Try varying font sizes
Speed
Access the site via a modem
Check image size specifications
Accessibility
Test accessibility
View in text browser
Browser independence
Try different browsers
Check printed pages
Switch Javascript off
Switch plug-ins off
Switch images off
Other checks
Check non-reliance on mailto
Check no orphan pages
Check sensible page titles

want full details...visit http://www.xs4all.nl/~sbpoley/webmatters/checklist.html

THINK OUT OF BOX AND FIND MORE BUGS

2007-08-03T01:23:00.001-07:00

Hi everyone,
For good software tester, out of box thinking is very essential. So that he can find some good bugs in the application. And make that application a fool proof one.

Let me give an example. If a programmer is coding for a Building Lift then he won't code for every floor. He may code for a single floor (like first floor) then slightly change the code and use that in other floors.
Here the out of box thinking works. If you test the application in every floor you may find some bugs, but a smart tester will specifically do testing for ground (lower) floor and the top (upper) floor.

The ground floor may not need the options for going down and the top floor don’t require going up.
This is how the out of box thinking works…

Regards,
-Jerry-

A Review of Error Messages

2007-07-27T04:26:00.000-07:00

What Does a Good Error Message Look Like?
A well-constructed error message

should identify the program that is posting the error message
should alert the customer to the specific problem
should provide some specific indication as to how the problem may be solved
should suggest where the customer may obtain further help
should provide extra information to the person who is helping the customer
should not suggest an action that will fail to solve the problem and thus waste the customer’s time
should not contain information that is unhelpful, redundant, incomplete, or inaccurate
should provide an identifying code to distinguish it from other, similar messages

Want to read more about error messages...visit
http://www.developsense.com/essays/AReviewOfErrorMessages.html

Thanks to MICHAEL

No User Would Ever Do That

2007-07-27T04:03:00.000-07:00

"No user would ever do that!"
"No user would ever try that!"
"No user would ever need that feature!"
"That's a cool idea, but no user would ever want it."

When developers say, "No user would ever do that," what they really mean is "No user that I've thought of, and that I like, would do that on purpose. In the Rapid Software Testing course, James and I have been encouraging testers to probe that statement for users that the developer didn't think of, for users that the developer doesn't like (like hackers or inexperienced users), or for things that legitimate, likable users might do by accident.

It recently occurred to me, though, that developers often say this after a tester has done something that has surprised the developer. "No user would ever do that!" "Well, I'm a user, and I just did it." "Yeah, but... you're not a real user."

One implication from this exchange is that testers aren't real users. Another is that testers' questions, actions, requirements, needs, and tactics don't matter. Fair enough--but let's keep that idea in mind, and maybe revisit it, when we hear another common software development question: "Why did it take you so long to find that bug?"

Posted by MICHAEL in his BLOG....Thanks to him

Ten Commandments of Software Testing

2007-07-23T04:19:00.000-07:00

Testing is harder than living. There are 15:

1.Stay alert
2.Run the tests as written
3.Keep an activity log
4.Document any problems encountered
5.Re-run the tests as they should have been written
6.Understand the system.
7.Understand the people.
8.Understand the tests.
9.Understand the requirement.
10.Understand the dependencies
11.Hope for the best
12.Prepare for the worst
13.Expect the unexpected.
14.Don't fake any results.
15.Agitate for improvement

Thanks to David Smiles

Tips on Writing Bug ReportsHow to Write a Bug Report

2007-07-23T04:14:00.000-07:00

1. Be very specific when describing the bug. Don’t let there be any room
for interpretation. More concise means less ambiguous, so less clarification
will be needed later on.

2. Calling windows by their correct names (by the name displayed on the
title bar) will eliminate some ambiguity.

3. Don’t be repetitive. Don’t repeat yourself. Also, don’t say things
twice or three times.

4. Try to limit the number of steps to recreate the problem. A bug that is
written with 7 or more steps can usually become hard to read. It is usually
possible to shorten that list.

5. Start describing with where the bug begins, not before. For example,
you don't have to describe how to load and launch the application if the
application crashes on exit.

6. Proofreading the bug report is very important. Send it through a spell
checker before submitting it.

6. Make sure that all step numbers are sequenced. (No missing step numbers
and no duplicates.)

8. Please make sure that you use sentences. This is a sentence. This not
sentence.

9. Don’t use a condescending or negative tone in your bug reports. Don’t
say things like "It's still broken", or “It is completely wrong”.

10. Don’t use vague terms like “It doesn’t work” or “not working properly”

11. If there is an error message involved, be sure to include the exact wording
of the text in the bug report. If there is a GPF (General Protection Fault) be
sure to include the name of the module and address of the crash.

12. Once the text of the report is entered, you don’t know whose eyes will see
it. You might think that it will go to your manager and the developer and
that’s it, but it could show up in other documents that you are not aware of,
such as reports to senior management or clients, to the company intranet, to
future test scripts or test plans. The point is that the bug report is your
work product, and you should take pride in your work.

Thanks to Bernie Berger

Xtreem Programming or Xtreem Testing

2007-07-23T03:59:00.000-07:00

At STAREast 2007, James Bach told a story of a project he once worked on. The project’s methodology was somewhat traditional, in the sense that developers wrote code and testers then performed inspective testing of the application. James found numerous bugs, reporting them back. This seemed to cause the programmer some frustration. James told of the programmer complaining… “why don’t you just tell me what tests you’re going to do and I’ll make sure that the code passes them before I give it to you?”

I liked the story… I now use it to explain something to the teams I work with.

After telling the story, I ask “What if we could tell the developer what tests we’re going to do in advance”?

This is exactly the opportunity presented in the development element of extreme programming where implementation is driven by Acceptance Tests. The key difference is that the process of ‘telling the programmer what tests the code needs to pass’ is a collaborative activity. The Acceptance Tests are arrived at in collaboration between tester, programmer and the customer.

This way, when we get the code, we know that all ‘reasonable’ tests that we can think of are accounted for in advance and (ideally) automated.

Because we are human and time is limited, there will always be tests that we simply can’t be expected to think of in advance. This is where Exploratory Testing comes in handy. By interacting with the application we realise what previously unaccounted for behaviours have been enabled by our development efforts.

Sometimes the outcome of these behaviours is highly undesirable… i.e. bugs. I simply think of these bugs as ‘gaps in our collective thinking’… gaps that we identify as additional tests that reveal a new User Story - that we implement soon after in a subsequent iteration. If it is urgent enough, ‘the team’ (programmers, testers etc) and ‘the customer’ may decide to implement it immediately, instead of work we’ve already planned in the current iteration. With short 1-2 week iterations, it’s gotta be pretty darn urgent before that happens.

An wonderful article on Manual and Automation Testing

2007-07-16T23:57:00.000-07:00

Thoughts on the Coexistence of Full Test Automation and Manual Testing

Published: April 3, 2007

by Colin Armitage

http://www.itjungle.com/fhs/fhs040307-story03.html

New kind of web testin - Web Service Testing

2007-07-09T03:48:00.000-07:00

Dear Friends,

This is the very latest thing in Web Testing....
Web Service Testing. To do this you r inneed of very good
web service knowledge and some good tool...here is an rare
tool of a kind...

"http://www.stylusstudio.com/ws_tester.html"

Surfe and Enjoy

- jerry

Web Page Stress test using Microsoft WAS

2007-07-09T03:40:00.000-07:00

Hi Friends,

Here is the link to learn, do web (stress) test using
Microsoft's Web Applicaiton Stress....

"http://www.west-wind.com/presentations/webstress/webstress.htm"

Thanks to west-wind.

Enjoy and Explore...

- jerry

Basic Guidelines and Checklist for Website Testing

2007-07-08T23:28:00.000-07:00

Hi Friends.
Here is an intresting PPT for a good web testing...

http://www.authorstream.com/presentation.aspx?pun=pawan-357-basic-guidelines-and-checklist-for-website-testing-PowerPoint

Enjoy and Learn

The words l like the most in tamil

2007-06-25T06:56:00.000-07:00

உணர்ந்துகொள்
நீ தோல்வியுற்றது
வாழ்க்கையிலல்ல
வாழ்க்கையை புரிதலில்...

Code to check if a parameter exists in DataTable or not.

2007-06-18T04:28:00.000-07:00

code:
on error resume next
val=DataTable(”ParamName”,dtGlobalSheet)
if err.number<> 0 then
‘Parameter does not exist
else
‘Parameter exists
end if

Here is the code for the Pass/Fail status of a check point.

2007-06-18T04:07:00.000-07:00

chk_PassFail = Browser(…).Page(…).WebEdit(…).Check (Checkpoint(”Check1″))
if chk_PassFail then
MsgBox “Check Point passed”
else
MsgBox “Check Point failed”
end if

story of a LITTLE bird

2007-06-13T07:10:00.000-07:00

A little bird was flying south for the winter. It was so cold; the bird froze and fell to the ground in a large field. While it was lying there, a cow came by and dropped some dung on it. As the frozen bird lay there in the pile of cow dung, it began to realize how warm it was. The dung was actually thawing him out! He lay there all warm and happy, and soon began to sing for joy. A passing cat heard the bird singing and came to investigate. Following the sound, the cat discovered the bird under the pile of cow dung, and promptly dug him out and ate him!

Management Lessons:
1) Not everyone who drops shit on you is your enemy.
2) Not everyone who gets you out of shit is your friend.
3) And when you're in deep shit, keep your mouth shut!

thAts wAt they R thinking

2007-06-13T07:01:00.000-07:00

1) Project Manager is a Person who thinks nine women can
 deliver a baby in One month.
2) Developer is a Person who thinks it will take 18 months
 to deliver a Baby.
3) Onsite Coordinator is one who thinks single woman can
deliver nine babies in one month.
4) Client is the one who doesn't know why he wants a baby.
5) Marketing Manager is a person who thinks he can deliver
 a baby even if no man and woman are available.
6) Resource Optimization Team thinks they don't need a man
 or woman; they'll produce a child with zero resources.
7) Documentation Team thinks they don't care whether the
 child is delivered, they'll just document 9 months.
8) Quality Auditor is the person who is never happy with the
 PROCESS to Produce a baby.
9) Tester is a person who always tells his wife that this is
 not the Right baby

Top 24 replies by programmers when their programs don't work:

2007-06-13T06:56:00.000-07:00

24. "It works fine on MY computer"
23. "Who did you login as ?"
22. "It's a feature"
21. "It's WAD (Working As Designed)"
20. "That's weird..."
19. "It's never done that before."
18. "It worked yesterday."
17. "How is that possible?"
16. "It must be a hardware problem."
15. "What did you type in wrong to get it to crash?"
14. "There is something funky in your data."
13. "I haven't touched that module in weeks!"
12. "You must have the wrong version."
11. "It's just some unlucky coincidence."
10. "I can't test everything!"
9. "THIS can't be the source of THAT."
8. "It works, but it's not been tested."
7. "Somebody must have changed my code."
6. "Did you check for a virus on your system?"
5. "Even though it doesn't work, how does it feel?"
4. "You can't use that version on your system."
3. "Why do you want to do it that way?"
2. "Where were you when the program blew up?"
1. "I thought I fixed that."

Why we need reviews.

2007-06-13T06:52:00.000-07:00

In an ancient monastery in a far away place, a new monk arrived to join his brothers in copying books and scrolls in the monastery's scriptorium. He was assigned as a rubricate on copies of books that had already been copied by hand.

One day, while working on the monks' Book of Vows, he asks old Father Florian, the Armarius of the Scriptorium, 'Does not the copying by hand of other copies allow for chances of error? How do we know we are not copying the mistakes of someone else? Are they ever checked against the original?'

Fr. Florian was set back a bit by the obvious logical observation of this youthful monk. 'A very good point, my son. I will take one of the latest copies of the Book of Vows down to the vault and compare it against the original.' Fr. Florian went down to the secured vault and began his verification.

A day passed and the monks began to worry and went down looking for the old priest. They were sure something may have happened. As they approached the vault they heard sobbing and wailing... they opened the door and found Fr. Florian crying over the new copy and the original, ancient Book of Vows, both opened before him on the table. It was obvious to all that the poor man had been crying his old heart out for a long time.

'What is the problem, Reverend Father???' asked one of the monks.

'Oh, my Lord,' sobbed the priest, 'The word is 'CELEBRATE'!!!'

And this is why we need reviews.

Testing Certifications

2007-06-13T06:45:00.001-07:00

Testing certifications

CSTE offered by the Quality Assurance Institute (QAI)
CSTP offered by the International Institute for Software Testing
ISEB offered by the Information Systems Examinations Board
ISTQB offered by the International Software Testing Qualification Board

Quality assurance certifications

CSQE offered by the American Society for Quality
CSQA offered by the Quality Assurance Institute (QAI)

zen and moon

2007-06-13T06:42:00.001-07:00

A Zen Master lived the simplest kind of life in a little hut at the foot of a mountain. One evening, while he was away, a thief sneaked into the hut only to find there was nothing in it to steal. The Zen Master returned and found him. "You have come a long way to visit me," he told the prowler, "and you should not return empty handed. Please take my clothes as a gift." The thief was bewildered, but he took the clothes and ran away. The Master sat naked, watching the moon. "Poor fellow," he mused, " I wish I could give him this beautiful moon."

zen and tea cup

2007-06-13T06:39:00.000-07:00

A university professor went to visit a famous Zen master. While the master quietly served tea, the professor talked about Zen. The master poured the visitor's cup to the brim, and then kept pouring. The professor watched the overflowing cup until he could no longer restrain himself. "It's overfull! No more will go in!" the professor blurted. "You are like this cup," the master replied, "How can I show you Zen unless you first empty your cup."

Cost of Quality

2007-06-13T06:33:00.000-07:00

1. Failure cost
2. Appraisal cost
3. Prevention cost

Verification and Validation

2007-06-13T06:31:00.000-07:00

Verification : are we building the product right?
Validation : are we building the right product?

Phases in SDLC

2007-06-13T06:19:00.000-07:00

1. Software requirements engineering
2. Software Design
3. Implementation
4. Testing
5. Maintenance

Levels and Process Areas of CMMI-SW

2007-05-31T21:31:00.001-07:00

1. Initial
2. Managed
# Requirements Management
# Project Planning
# project Monitoring and Control
# Supplier Agreement and Management
# Measurement and Analysis
# Process and Product Quality Assureance
# Configuration Management
3. Defined
4. Quantitatively Managed
5. Optimizing

(will be updated soon...)

5 Levels of SW-TMM

2007-05-31T21:26:00.000-07:00

1. Initial
2. Phase definition
3. Integration
4. Management and measurement
5. Optimization / defect prevention and quality control

Types of Defects

2007-05-31T21:23:00.000-07:00

1. Functional Defects.
2. Non-Functional Defects.
3. Security -related.
4. Safety -related.
5. External interface related.
6. Conformance related.
7. Portability related.
8. Usability related.
9. Testability related

Black Box Test Case Design Techiniques

2007-05-31T21:19:00.000-07:00

Here some of the Black Box Test Case Design Techiniques...
1. Specification Based Testing
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Cause Effect Analysis
5. State Transition Diagrams
6. Use Case Based Design

TeSTErs JoKEs - 2

2007-05-29T21:07:00.000-07:00

1) Project Manager is a Person who thinks nine women can deliver a baby in One month.
2) Developer is a Person who thinks it will take 18 months to deliver a Baby.
3) Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.
4) Client is the one who doesn't know why he wants a baby.
5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
6) Resource Optimization Team thinks they don't need a man or woman; they'll produce a child with zero resources.
7) Documentation Team thinks they don't care whether the child is delivered, they'll just document 9 months.
8) Quality Auditor is the person who is never happy with the PROCESS to Produce a baby.
9) Tester is a person who always tells his wife that this is not the Right baby

TeSTErs JoKEs

2007-05-29T21:04:00.000-07:00

When you have an "I hate my job" day try this: On your way home from work, stop at your pharmacy and go to the thermometer section. You will need to purchase a rectal thermometer made by Johnson and Johnson. Be very sure you get this brand. When you get home, lock your doors, draw the drapes, and disconnect the phone so you will not be disturbed during your therapy. Change to very comfortable clothing, such as a sweat suit and lie down on your bed. Open the package and remove the thermometer. Carefully place it on the bedside table so that it will not become chipped or broken. Take out the material that comes with the thermometer and read it. You will notice that in small print there is a statement: "Every rectal thermometer made by Johnson and Johnson is personally tested. " Now close your eyes and repeat out loud five times: "I am so glad I do not work for quality control at the Johnson and Johnson Company. "

Wanna Define Software Testing

2007-05-23T00:16:00.000-07:00

Most of the time, people asked to define Testing....
But my view on that definition is this---------
IS IT Possible to Define LOVE
if u asked this question to a person who was not experienced love...he may define something..
but, for a person who experienced LOVE..., he can't define anything...
the truth is this, if u understand something truly like LOVE, FRIENDSHIP, FAMILY, GOD, ZEN....then u cant define it.

Like the same, if u understanded what testing is...then u cant define it.
ITS JUST ..MORE THEN THAT.