Guidelines while developing software Product
Strings
empty string
String consisting solely of white space
String with leading or trailing white space
syntactically legal: short and long values
syntactically legal: semantically legal and illegal values
syntactically illegal value: illegal characters or combinations
Make sure to test special characters such as #, ", ', &, and <
Make sure to test "Foreign" characters typed on international keyboards
Numbers
empty string, if possible
0
in range positive, small and large
in range negative, small and large
out of range positive
out of range negative
with leading zeros
syntactically invalid (e.g., includes letters)
Floating values
Identifiers
empty string
syntactically legal value
syntactically legal: reference to existing ID, invalid reference
syntactically illegal value
Radio buttons
one item checked
nothing checked, if possible
Check boxes
checked
unchecked
Drop down menus
select each item in turn
Scrolling Lists
select no item, if possible
select each item in turn
select combinations of items, if possible
select all items, if possible
File upload
blank
0 byte file
long file
short file name
long file name
syntactically illegal file name, if possible (e.g., "File With Spaces.tar.gz")
Data type
Name(First name,Last name) should be in alphabets
Address in alphanumeric
Telephone no,mobile should be according to clients requirement(Numeric/Alphanumeric)
Check that phone no should contain special characters or not
Password should be in encrypted format
Check that Email should contain the format
Browser Compactibility
Check that application runs on different browser like Internet Explorer,Netscape,Mozilla,Firefox,Opera
Images
Check the type of image(jpg,jpeg,bmp.gif)
Maximum size
Compactibility with other browser
Resolution
Clarity of the image
Web site testing
Consideration should be given to the interactions between html pages, TCP/IP communications,
Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).
There are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols.
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times).
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
What is a good Code
Minimize or eliminate use of global variables.
use descriptive function and method names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable.
function descriptions should be clearly spelled out in comments preceding a function's code.
organize code for readability.
use whitespace generously - vertically and horizontally
each line of code should contain 70 characters max.
one code statement per line.
coding style should be consistent throught a program (eg, use of brackets, indentations, naming conventions, etc.)
in adding comments, err on the side of too many rather than too few comments; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code.
no matter how small, an application should include documentaion of the overall program function and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation.
make extensive use of error handling procedures and status and error logging.
for C++, to minimize complexity and increase maintainability, avoid too many levels of inheritance in class heirarchies (relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator overloading (note that the Java programming language eliminates multiple inheritance and operator overloading.)
for C++, keep class methods small, less than 50 lines of code per method is preferable.
for C++, make liberal use of exception handlers
Web Design Mistakes
Poor load time
Poor overall appearance
Spelling/Grammar mistakes
No contact information
Poor content
Poor navigation
Broken links and graphics
Poor browser compatibility
Large slow loading graphics
Too many graphics
Pages scrolling to oblivion
Multiple use of animated graphics
Animated bullets
Too many graphic and/or line dividers
Busy, distracting backgrounds
Multiple banners and buttons
Poor use of frames
Large fonts
Pop up messages
Over use of Java
Poor use of tables
Poor organization
Different backgrounds on each page
Over powering music set to AutoPlay
Confusing
Too much advertising
Large Welcome banners
Multiple colored text
Text difficult to read
No Meta tags
Multiple use of different fonts
Under construction signs
Scrolling text in the status bar
Large scrolling text across the page
Poor use of mouse over effects
Take your time and design your site very carefully. It may take you a little longer, but it will be well worth the extra time in the long run.
What is Good Design
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented.
Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. the program should act in a way that least surprises the user
What can be done if requirements are changing continuously?
This is a common problem for organizations where there are expectations that requirements can be pre-determined and remain stable. If these expectations are reasonable, here are some approaches:
Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
If the code is well-commented and well-documented this makes changes easier for the developers.
Use some type of rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
The project's initial schedule should allow for some extra time commensurate with the possibility of changes.
Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version.
Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job.
Balance the effort put into setting up automated testing with the expected effort required to refactor them to deal with changes.
Try to design some flexibility into automated test scripts.
Focus initial automated testing on application aspects that are most likely to remain unchanged.
Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).
Common problems in software development
poor requirements - if requirements are unclear, incomplete, too general, and not testable, there will be problems.
unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash.
featuritis - requests to pile on new features after development is underway; extremely common.
miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed.
How to overcome to software development problems?
solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. Use prototypes to help nail down requirements. In 'agile'-type environments, continuous close coordination with customers/end-users is necessary.
realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.
adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. 'Early' testing ideally includes unit testing by developers and built-in testing and diagnostic capabilities.
stick to initial requirements as much as possible - be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, work closely with customers/end-users to manage expectations. This will provide them a higher comfort level with their requirements decisions and minimize excessive changes later on.
communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - groupware, wiki's bug-tracking tools and change management tools, intranet capabilities, etc.; insure that information/documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use protoypes and/or continuous communication with end-users if possible to clarify expectations.
Why does software have bugs?
miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements).
software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Multi-tiered applications, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity.
programming errors - programmers, like anyone else, can make mistakes.
changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc.
If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
egos - people prefer to say things like:
'no problem'
'piece of cake'
'I can whip that out in a few hours'
'it should be easy to update that old code'
poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').
software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.
|
