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
- Test the application for multi-languages, multi-time zones, multi-browsers, multi-screen sizes, multi-platforms whichever are applicable
- Test the application for key board short cuts, tooltips for form elements, dropdown heights/widths, textbox height/widths and overall symmetry
- Test the application for formatting, location, window sizes of all user friendly warning/error messages and their respective triggers
- Test the application for SQL Injection (exploits a security vulnerability occurring in the database layer of an application)
- Test the application for illegal (over limit, under limit, different data types, null) inputs
- Test the source code for “Reflection”, hence no variable/class/method names should be hard coded
- Print all the output reports and test them for alignment, proper page breaks, formatting, paper size, data readability and completeness
- 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
- 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
- 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
- Test the application for SOX (The Sarbanes-Oxley Act) compliance, following the SOX compliant controls from ISO 27001
- Three levels of testing should be practised:
- Programmer’s testing for illegal inputs, source code verification, code optimisation, appropriate documentation, testing all permutations and combinations of inputs and respective outputs
- 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
- 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
Encrypt/encode the source code and place it in a secured network drive
- 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