Situational testing

Every organization, every system and every project is different, so every test project requires a unique approach. Situational testing offers various forms of testing and allows you to complete your testing projects flexibly, at the lowest possible cost and in the shortest possible time.
 
Among the forms of testing recognized within Situational testing are factory based testing, global scripting, session based testing, bug hunts, test tours and free style exploratory testing. Testers choose one or more of these test forms, depending on the organization, project and system. This way, Situational testing encourages you to approach testing in a flexible, structured and pragmatic fashion. With Situational testing you achieve better results than using a single specific approach.

Clean Code


Points to remember
•Make it easy to read,
•Make the surrounding code clean,
•Change one variable name for the better,
•Break up one function that’s a little too large,
•Eliminate one small bit of duplication,
•Clean up one composite if statement.
•Use meaningful names
•Distinguish names in such a way that the reader knows what the differences offer
•Use Pronounceable Names

Functions
•Functions should be small. They should do one thing. They should do it well. They should do it only.
•We want to read the code like a top-down narrative.
•Use descriptive names for functions.
•Switch statements should be buried deep in a low-level class and should never be repeated.
•Use Descriptive names for the functions. The smaller and more focused a function is, the easier it is to choose a descriptive name.
•For a function three or more arguments should be avoided. Ideal is zero arguments.
•Flag arguments are ugly.
•When a function needs more than two or three arguments then wrap the arguments into a class of their own.
•Functions should either do something or answer something, but not both.
•Extract the bodies of the try and catch blocks out into functions of their own.
•Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it.

Comments
•Adding comments is not good as it shows your failure in writing an expressive code.
•Either spend your time writing the comments that explain the mess you’ve made or spend it cleaning that mess.
•Don’t Use a Comment When You Can Use a Function or a Variable
•Comments are good only if they
–Meant for legal documentation
–Provide Informative value for a complex regular expression or formula
–Explain the intent or business requirement
–Clarify the third party library or API usage
–Warn about consequences
–Denote TODO tasks
–Amplify the importance of something

Formatting
•Code formatting is about communication, and communication is the professional developer’s first order of business
•A team of developers should agree upon a single formatting style, and then every member of that team should use that style.
•The reader needs to be able to trust that the formatting gestures he or she has seen in one source file will mean the same thing in others.
•Vertical Size: Small files are usually easier to understand than large files are
•Source file should appear like a newspaper article.
•Horizontal Size:  Strive to keep our lines short