Testing During Development

INFO-6067
 Why Do We Care?
• We are Quality Assurance, why do we care about testing during the
development process? We will explore the following:
• Why developers should test
• How developers test
• Different approaches to testing during the SDLS (Software development life
cycle)
• How does developer testing affect my roles as QA?
• What is continuous testing?
 Why Should Developers Test
• The Objective of developer testing is to eliminate construction errors
before code is passed to QA
• Companies are gauging a developer’s skill by lack of defects in code vs the
number of lines of code written
• Quality over Quantity
• Coding errors, even if small can cause a tedious amount of work if found
downstream by QA. (additional time and cost)
• Rework in fixing errors is inefficient and costly.
• Significant errors can result in project failure.
 Why Should Developers Test
• Testing earlier allows us to catch defects faster
• We can become more flexible as we can verify new code/features do
not break or introduce defects into the code base

• At the end of the day, earlier testing by developers avoids long

QA/bug fix cycles allowing a shorter overall time to production
 How Do Developers Test?
• Code Reviews
• Unit Testing
• Integration Testing
• Static Analysis
• Automated Tools
 Code Reviews
• A systematic examination (sometimes referred to as peer review) of
source code. It is intended to improve the overall quality of software.
• When done correctly, peer reviews save time by reducing the number
of defects that find their way to the QA stage
• Looks for logic errors, potential security concerns, typos, adherence
to design requirements and compliancy with best practices.
 Code Review Process
• Takes place during all phases of development
• Normally when merging a new feature into a code base

• Steps:
• Identify the code to be reviewed
• Normally automated using a diff tool
• Identify the participants in the review
• Reviewers, developers that worked on the code
• Code in then reviewed by participants either individually or as a team
• Compare against the design and the business requirements
• Compare code against industry and corporate coding best practices and standards
• Records all deviations
• Return to developer to correct deviations
 Code Review Tips
• Code Developer
• Provide context
• We are not reviewing the entire code base every time
• Having some context will help understand where the code fits and how it interacts with
the existing code
• No Huge Reviews
• Typically, you want to be reviewing less than 200 lines of code
 Code Review Tips
• Code Reviewer
• Have a checklist
• Know what you are looking for
• Review All Code
• Don’t just skim
• Be positive when reporting defects
• Be constructive
• Don’t criticize
• Follow-up
• Ensure that issues found during the review are corrected
• Simple email, ask at the water cooler
• Deny code merge until code corrected
 Unit Testing
• A testing method by which individual units of source code, together
with associated control data, usage procedures, and operating
procedures, are tested to determine whether they are fit for use
• A Unit
• The smallest testable part of an application
• Can be a whole module or single class but is typically an individual function
 Integration Testing
• A testing method where individual modules or components are tested
together to ensure compatibility, functionality, reliability and
performance
• Normally done by developers to ensure the code they have developed
works with code that already exists in the system
• May be a new module coded by the developer
 Integration Testing
• Components, modules that need to interrelate will have a defined
interface
• A developer will need to comply with the defined interface to ensure
their code works correctly with other components
• Communication protocols may also be defined
• What data is passed to and received from the other components
• Integration testing will test the interface(s) and the protocols
 Static Analysis
• A method of testing without executing the source code.
• Can reveal errors that do not manifest themselves until a disaster
occurs weeks, months or years after release.
• Can uncover security vulnerabilities, back doors, malicious code.
• Can look for inefficiencies, bad coding habits, poor memory
management techniques.
• Typically performed using automated tools.
 Static Analysis
• Tools are typically designed to target a specific outcome.
• The tool is configured where applicable
• The tool is run against the target code
• Target code can be a single class or the entire application
• The tool will generate output such as reports which may also contain
suggestions to repair/remediate the code.
• When the code is modified the tool is generally run again (and usually run
multiple times throughout the coding cycle)
 Static Analysis Tools
• RIPS – www.ripstech.com
• PVS Studio – www.viva64.com
• HP Fortify – www.microfocus.com
• Gamma – mygamma.io
• Parasoft – www.parasoft.com
• W3.org– W3C validation
 Automated Tools
• Automated testing tools can be used by developers during coding.
(Selenium, TestComplete, SoapUI etc.)
• The same tools used by QA can be used by developers.
• Many of the automated tools support end to end testing.
• Test scripts can be written by developers to support their
development testing and used downstream during QA.
 Automated Tools
• Test cases are written by developers from an implementation
perspective
• The test cases do not replace or negate test cases written by QA, they
supplement
• The appropriate test cases are then transformed into test scripts for
the tool(s) being used
• The scripts are executed as part of the developers test library
• May be used during unit testing or integration testing or prior to
promotion of the source code to QA
Questions?
 Lab 1 – Code Review
• Let’s look at a basic code review checklist:
Checklist Item Category

Use Intention-Revealing Names Meaningful Names

Pick one word per concept Meaningful Names

Use Solution/Problem Domain Names Meaningful Names

Classes should be small! Classes

Functions should be small! Functions

Do one Thing Functions

Don't Repeat Yourself (Avoid Duplication) Functions

Explain yourself in code Comments

Make sure the code formatting is applied Formatting

Use Exceptions rather than Return codes Exceptions

Don't return Null Exceptions

 Lab 1 – Code Review
Checklist Item Category

Make class final if not being used for inheritance Fundamentals

Avoid duplication of code Fundamentals

Restrict privileges: Application to run with the least privilege mode required for functioning Fundamentals

Minimize the accessibility of classes and members Fundamentals

Document security related information Fundamentals

Input into a system should be checked for valid data size and range Denial of Service

Avoid excessive logs for unusual behavior Denial of Service

Release resources (Streams, Connections, etc) in all cases Denial of Service

Purge sensitive information from exceptions (exposing file path, internals of the system, configuration) Confidential Information

Do not log highly sensitive information Confidential Information

Consider purging highly sensitive from memory after use Confidential Information

Avoid dynamic SQL, use prepared statement Injection Inclusion

Limit the accessibility of packages, classes, interfaces, methods, and fields Accessibility Extensibility

Limit the extensibility of classes and methods (by making it final) Accessibility Extensibility

Validate inputs (for valid data, size, range, boundary conditions, etc) Input Validation

Validate output from untrusted objects as input Input Validation

Define wrappers around native methods (not declare a native method public) Input Validation

Treat output from untrusted object as input Mutability

Make public static fields final (to avoid caller changing the value) Mutability

Avoid exposing constructors of sensitive classes Object Construction

Avoid serialization for security-sensitive classes Serialization Deserialization

Guard sensitive data during serialization Serialization Deserialization

Be careful caching results of potentially privileged operations Serialization Deserialization

Only use JNI when necessary Access Control

 Lab 1 – Code Review

Checklist Item Category

Avoid excessive synchronization Concurrency

Keep Synchronized Sections Small Concurrency

Beware the performance of string concatenation General Programming

Avoid creating unnecessary objects Creating and Destroying Objects

 Lab 1 – Code Review
Category Checklist Item

Use checked exceptions for recoverable conditions and runtime exceptions for programming errors Exceptions

Favor the use of standard exceptions Exceptions

Don't ignore exceptions Exceptions

Check parameters for validity Methods

Return empty arrays or collections, not nulls Methods

Minimize the accessibility of classes and members Classes and Interfaces

In public classes, use accessor methods, not public fields Classes and Interfaces

Minimize the scope of local variables General Programming

Refer to objects by their interfaces General Programming

Adhere to generally accepted naming conventions General Programming

Avoid finalizers Creating and Destroying Objects

Always override hashCode when you override equals General Programming

Always override toString General Programming

Use enums instead of int constants Enums and Annotations

Use marker interfaces to define types Enums and Annotations

Synchronize access to shared mutable data Concurrency

Prefer executors to tasks and threads Concurrency

Document thread safety Concurrency

 Lab 1 – Code Review
• Download all the files from the submission folder called ‘Lab1 - Code
Review’
• Follow the instructions in ‘Lab 1 - Code Review.docx’