A handy checklist for testers and programmers

As a programmer I always felt the desire and importance of a handy checklist which could help programmers and testers to code and test their applications. After lots of research, I made one which is presented below. Please feel free to comment and provide suggestions and feedbacks.

 

Source Code Testing:

 

1.      Source Code history

2.      Use of readable indentation for source code

3.      Source Code optimization

4.      Source Code Comment documentation

5.      Source Code Backup

6.      Appropriate naming conventions for source files

7.      Appropriate storage location for source files

8.      Appropriate use of Transactions wherever required

9.      Appropriate use of Stored Procedures wherever required

10.  Use of functions for code reuse

11.  Use of Common library

12.  CSS Code to be separated from the source code

13.  AJAX code to be separated from the source code

14.  Use of version control mechanism

15.  Source Code encryption mechanism

16.  Appropriate use of sessions / cookies

17.  LDAP authentication

18.  Following the standards. (for e.g. XHTML 1.0 standard for web coding).

19.  Appropriate naming conventions for functions used and functions in the common library

20.  Appropriate folder structure for source code files

21.  Clearance of extra comments, unnecessary code, echoes, alerts, type texts

22.  No hard coding should be present

 

Database Testing:

 

1.      Appropriate linking of tables

2.      Normalization

3.      Naming Conventions for databases, tables, stored procedures etc

4.      Appropriate storage engine is used

5.      Optimized field types are used

6.      Database backup function

7.      Appropriate use of Triggers

8.      Encrypted storage of confidential data

9.      Compressed storage of big data

10.  Appropriate prefixing for special characters before storage

11.  Scalability of database

12.  Database Document – Design schema with sample data

13.  Appropriate filtering of data before storing into the database

14.  Appropriate default values for table fields

15.  Appropriate comments entered for table fields

16.  Database Design query with sample data to be documented

 

UI Testing:

 

1.      Consistency of screens

2.      Consistency of background colours

3.      Usage of pleasant colours

4.      IPR violation with logos, images, colours, text

5.      Consistency across multiple browsers (IE, Mozilla, Netscape)

6.      All controls on the screen should be accessible through keyboard / Keyboard shortcuts

7.      Various screen sizes testing

8.      Various Platforms testing

9.      Best Configuration message on home page

10.  Appropriate tool tips for all elements on UI

11.  All dropdowns heights and widths, symmetry and consistency

12.  Textboxes height and width

13.  Overall symmetry

14.  Print all the output reports and test them for alignment, proper page breaks, formatting, paper size, data readability and completeness

15.  Scalability for various technologies, if yes, define configuration and process steps for migration

16.  Backup function

17.  Backup Procedure documented

18.  Auto/Manual Backup

19.  All necessary documentations: commenting the code, flow chart, database design/schema, table design/scheme, user manual, source code/files naming conventions, ER diagram, help files, researched material

20.  Testing for SOX compliancy

21.  Overall user friendliness & aesthetics

22.  Should be best viewable with 800×600 resolution

23.  Maximizing, minimizing, resizing of windows to be possible

24.  Positioning of cursor on the first editable field in Data entry screens

25.  Every screen should have one Default button

26.  Acknowledgment of error messages should take the control to where the error occurred

27.  The Title bar should contain appropriate title

28.  Every screen should have a title/header

29.  Ease of use without any help

30.  Grammatical correctness of error messages

31.  Correct grammar for texts, field names and tool tips

32.  Grammatical correctness of Help text

33.  Text box lengths should correspond the length of data they take, wherever possible

34.  Default values to be populated wherever possible

35.  Consistent behaviour when screen resolution is changed

36.  Consistency of margins and header and footer

37.  Consistency of Colour of form

38.  Consistency of Size of form

39.  Consistency of fonts used for labels

40.  Consistency of Size of buttons

41.  Consistent use of animations/graphics

42.  Consistency of labelling of controls (buttons, boxes)

43.  Consistency of length of textboxes for the same field

44.  Consistency of formats for date fields

45.  Effective reuse of repeatable visual themes:
-When a button is clicked
-When an error is encountered
-When a field is being validated

46.  Should support users’ sequence of accomplishing a task

47.  ‘Back’ and ‘Home’ links to be provided

48.  Correct order of tabbing

49.  Text to be selected when tabbing to a textbox

50.  All tab controls should be accessible thru’ keyboard

51.  Shortcut keys (hot keys) to be unique

52.  Links should be obvious and consistent

53.  Functioning of the ‘Back’ and ‘Forward’ functions of the browser

54.  Check if all links are active

55.  Alignment of labels

56.  Alignment of buttons

57.  Anything that needs user action must be communicated

58.  Feedback should be provided whenever relevant

59.  Minimum usage of pop-ups and message boxes

60.  User errors must be communicated

61.  Availability of Help feature

62.  Availability of Context-sensitive help, wherever needed

63.  Buttons should be enabled/disabled depending on context

64.  Non-editable text fields should be distinctly visible from others

65.  Messages and labels should be accurate and appropriate for the context

66.  Check if all links lead to meaningful points

67.  Use of familiar and comfortable language

68.  Abbreviations and code language to be used minimally

69.  Help and Search links should be distinctly visible

70.  Visible font for all text

71.  Avoid all CAPS text

72.  Help messages to be clear and concise

73.  Error messages to be clear and concise

74.  Should avoid horizontal scrolling

75.  Should avoid vertical scrolling as much as possible

76.  Logical ordering of controls

77.  Position of controls should be meaningful

78.  Grouping of related info. and data

79.  Appropriate label for grouped data

80.  Drop down/combo box menu to be ordered

81.  Toggling of checkboxes

82.  Checking/un checking of checkboxes through space-bar

83.  Single choice for radio-buttons

84.  Access keys (Keyboard shortcuts) letter should be underlined when visible on the UI

85.  Frozen grid titles

86.  Horizontal alignment of tables, body, div, span, data grid

87.  Vertical alignment of tables, body, div, span, data gird

88.  Mandatory fields should be distinctly marked in the UI

89.  Positioning of Pop Up windows

 

Functional Testing:

 

1.      Basic Data flow is working properly

2.      To be able to add data and save it correctly

3.      To be able to edit data correctly

4.      To be able to copy data correctly

5.      To be able to delete data correctly

6.      Cancel function

7.      Logout function

8.      Change Password feature

9.      Password Complexity

10.  Password History

11.  Various authentication levels

12.  Application should be accessible thru’ URL as well as IP address

13.  Time to load the application must be appropriate

14.  Search Function

15.  Search facility should be flexible (wildcards, mixed case, partial strings etc.)

16.  Prompt to save unsaved data while trying to move to next screen

17.  Password validation

18.  Field vs. form level validations

19.  Destructive actions to be confirmed

20.  UI shows navigation and user friendly message for null records in the database

21.  Search Engine Optimization (SEO)

22.  A “Contact us” page for maintenance team. The page should have mail id,  address and phone numbers

23.  Application should have a visible status bar – logged in user, logged in time, date

24.  A user confirmation while logging out or closing the application

25.  User should not be allowed to navigation to any of the application pages without logging in

26.  User session should auto expire within the following specified time period (5 minutes > Session Expiry time > 15 minutes)

27.  Highlighting of searched keywords should be present for Search feature

28.  All kinds of necessary validations for blank data inputs, illegal data inputs

29.  Warning, error window sizes and placement

30.  Test for SQL injection

31.  Testing for over limit, under limit, different data types, null inputs

32.  Testing for Reflection, no variable/class/method names should be hard coded

Project Mangement Model

Performance tuning guidelines

Performance tuning guidelines:

The following guidelines should help you develop an overall approach to performance tuning.

Remember the law of diminishing returns: Your greatest performance benefits usually come from your initial efforts. Further changes generally produce smaller and smaller benefits and require more and more effort.

Do not tune just for the sake of tuning: Tune to relieve identified constraints. If you tune resources that are not the primary cause of performance problems, this has little or no effect on response time until you have relieved the major constraints, and it can actually make subsequent tuning work more difficult. If there is any significant improvement potential, it lies in improving the performance of the resources that are major factors in the response time.

Consider the whole system: You can never tune one parameter or system in isolation. Before you make any adjustments, consider how it will affect the system as a whole.

Change one parameter at a time: Do not change more than one performance tuning parameter at a time. Even if you are sure that all the changes will be beneficial, you will have no way of evaluating how much each change contributed. You also cannot effectively judge the trade-off you have made by changing more than one parameter at a time. Every time you adjust a parameter to improve one area, you almost always affect at least one other area that you may not have considered. By changing only one at a time, this allows you to have a benchmark to evaluate whether the change does what you want.

Measure and reconfigure by levels: For the same reasons that you should only change one parameter at a time, tune one level of your system at a time. You can use the following list of levels within a system as a guide:

Hardware
Operating System
Application Server and Requester
Database Manager
SQL Statements
Application Programs

Check for hardware as well as software problems: Some performance problems may be corrected by applying service either to your hardware, or to your software, or to both. Do not spend excessive time monitoring and tuning your system when simply applying service may make it unnecessary.

Understand the problem before you upgrade your hardware: Even if it seems that additional storage or processor power could immediately improve performance, take the time to understand where your bottlenecks are. You may spend money on additional disk storage only to find that you do not have the processing power or the channels to exploit it.

Put fall-back procedures in place before you start tuning: As noted earlier, some tuning can cause unexpected performance results. If this leads to poorer performance, it should be reversed and alternative tuning tried. If the former setup is saved in such a manner that it can be simply recalled, the backing out of the incorrect information becomes much simpler.

Checklist for Programmers

It is shameful for a programmer to manage a blog and do not have articles about programming! I was constantly thinking about this for a long time and finally I decided to write one which is presented below.  

It is like a check list for programmers and testers to give a crowning touch to their codes/programs/applications/websites; although all steps may not be applicable to your applications but you can definitely use the ones which seem useful to you.  

I would appreciate all the technical people who read this article, if they jot their comments, suggestions for missing points and for mistakes/in accuracies, so that we all together can create a prime checklist for defining a completely new and secure vertical for the programmer and tester community across the globe. 

Testing redefined: Creating secure applications 

1. Test the application for multi-languages, multi-time zones, multi-browsers, multi-screen sizes, multi-platforms whichever are applicable
2. Test the application for key board short cuts, tooltips for form elements, dropdown heights/widths, textbox height/widths and overall symmetry
3. Test the application for formatting, location, window sizes of all user friendly warning/error messages and their respective triggers
4. Test the application for SQL Injection (exploits a security vulnerability occurring in the database layer of an application)
5. Test the application for illegal (over limit, under limit, different data types, null) inputs
6. Test the source code for “Reflection”, hence no variable/class/method names should be hard coded
7. Print all the output reports and test them for alignment, proper page breaks, formatting, paper size, data readability and completeness
8. Test the application for scalability to various databases, programming languages, operating systems and define a schedule for migration, minimum requirements – hardware, software and non-possible migrations
9. Create and test the backup schedule, backup copies should be placed in a different location, following the BCP-DR (Business continuity planning – Disaster recovery) procedure for ISO 27001. Backup schedule should be periodical i.e. daily, weekly, fortnightly, monthly, quarterly depending on the data availability factor for the application users
10. Maintain all the necessary documentation: commenting the code, flow chart, database design/schema, table design/scheme, user manual, source code/files naming conventions, ER diagram, help files, researched material etc
11. Test the application for SOX (The Sarbanes-Oxley Act) compliance, following the SOX compliant controls from ISO 27001
12. Three levels of testing should be practised:
13. Programmer’s testing for illegal inputs, source code verification, code optimisation, appropriate documentation, testing all permutations and combinations of inputs and respective outputs
14. Tester’s testing with a hacker’s perspective to break into/through the application and find all the loop holes possible. No security loop holes should be found once this testing is achieved
15. Users/Beta testing focussing towards user friendliness and aesthetic side of the application. Ease of use, efficiency, quick outputs in the desired formats, correctness and completeness are key points here
16. Encrypt/encode the source code and place it in a secured network drive
17. Create a schedule to backup source code or maintain versions with proper naming conventions using timestamp, programmer’s name, version number and maintain necessary documents (soft/hard copy) explaining the reasons for shifting to the newer version. Amend the documentation every time a new version is released, if version maintenance is applicable