2013 Issue

54 A database design checklist might contain items such as all table names must be singular, and all Boolean fields will be 1 position CHAR datatypes of either “T” and “F” values. Coding One trick if you have a strained quality assurance testing staff, is to have a construction review. This is not a code review, this is a review of a programmer’s work by another programmer. When a programmer completes his code and is ready to send it to testing, he first asks another programmer to try to break it. He does this right at his workstation, where it is very easy to immediately fix any found problems. Once the built code is stable, he can then send it to the testing group. In some cases, coding standards are important. Instead of doing a code review at the end of a developer’s efforts, a good idea is to perform a code review about 20% into a developer’s efforts, and then a follow-up review after they are about 80% complete. This practice finds bad habits early, and provides enough time for a coder to refactor any needed code and still meet a deadline. An extreme, but effective practice found in agile development communities, is the practice of Test Driven Development (TDD). TDD is the practice of creating test cases at the code level for every subroutine in the code. The TDD pattern is called “Red, Green, Clean,” and represents the following practice: 1) creating a subroutine shell 2) creating a test case that calls the subroutine 3) running the test case which returns a failure (“Red”) because there is no code inside it 4) completing the subroutines code and calling the test case again, hopefully returning a success (“Green”) 5) refactoring the code to optimize it for speed and readability All of these test cases are connected by one backbone test har- ness. Although this practice requires a little more overhead for the developers, it ensures 100% code test coverage, and makes maintaining an existing product extremely low-risk. As changes are made later to a product, all of the test cases can be run again and if any changes have broken other parts of the software the test harness will find the error before the customers will. Testing Testing should be tested at from different perspectives. Initially, a smoke-test should be performed, where the tester verifies all of the components are in place and have access to whatever data-store exists supplying their data. A simple exploration of every screen and triggering one function per screen to see if data access is present is a good idea. Without first performing a smoke test, testers may spend hours testingworking components to find additional needed Beyond testing | continued from page 53