Better Folder Structure

Here is an better folder structure for an project drive.

Cheers,
-jerry

A wonderful GUI Checklist from Rathish

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

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

Cheers,

-jerry and Team SST

30 Usability Issues to be aware of

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

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

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

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.. :-)