Software testing - executing a system or component under specified conditions

2 objectives of Software Testing;

Direct - To identify and reveal as many errors as possible in the tested software

Indirect - To compile a record of software errors for use in software

Unit Testing – performed by the developer

Integration Testing – project team performs this type of testing on the integrated systems

System Testing – tests the functionality of an entire system together with interdependencies between system
components

Performance Testing - to ensure that the performance of the system is within the bounds specified by the non-functional
requirements

Acceptance Testing – System users or customers

System and software design - partitions the requirements into hardware or software systems and builds the overall
system architecture

Intermediate design – software system is broken into components and then classes are associated with each component

Implementation design – the developers start writing and compiling classes and methods

System deployment – delivering a completed software product to clients

A test case or test scenario - is a software artifact with a set of test inputs, execution conditions, and expected results
developed for a particular objective

2 approaches to unit testing;

White-Box - verify the internal logic and program statements of components or software. It involves stepping through
every line of code and every branch in the code

Black-Box - tester derives tests from external descriptions of the software, including specifications, requirements, and
design

UNIT TESTING TOOLS

JUnit and TestNG - for Java programming language

NUnit - for all .NET language

test-driven development (TDD) - tests for the code are written before writing the code

Software deployment - delivering a completed software product to clients.

SOFTWARE DEPLOYMENT TOOLS

Automation - eliminates the manual tasks

Security - permission settings of users

Monitoring - monitors and analyses the activities and interactions of the software users

Jenkins - self-contained, open-source automation server that can be used to automate all activities related to building,
testing, and delivering or deploying software

Octopus Deploy - designed to automate application deployments in the cloud, corporate data center, and on-site

Bamboo - delivery aspect of continuous delivery

SolarWinds Patch Manager - automated patch management software for Microsoft servers, workstations, and third-
party applications

SOFTWARE QUALITY ASSURANCE

Software quality assurance - defect prevention, detection, and removal, as well as defect containment activities

Software inspection or software review - formalized peer review process for detecting and correcting defects or bugs in
software artifacts.

Fagan inspection methodology - to identify and remove errors in the software products and to identify any systematic
defects in the processes that are used to create software products. -developed by Michael Fagan

Moderator - leads the inspection team and takes care of logistics.

Reader - who can be a subject matter expert on the software artifacts under inspection

Tester - responsible for writing and executing test cases for the software module

Structured Walkthrough - peer review in which the author of a deliverable, such as a document or source code, brings
one (1) or more reviewers through the deliverable

Code reviewing or inspection - systematically convening with fellow programmers to check each other’s code for faults
to ensure the code meets quality standards

2 famillies approaches to identify defects in source code;

Tool-Driven Code Review - uses automated code analysis techniques that can pick out problematic patterns

Developer-Driven Code Review - the developers themselves reviews the code to pick out problems

Modern code review - does not rely on face-to-face meetings

2 version repository;

Tool-Driven Code Review - used by version control systems to store multiple versions of files that can be accessed by
multiple user

Pull-Based Development - revolves around a mechanism known as a “pull request.”

DESIGN PRINCIPLES AND PATTERNS

3 important characteristics of a bad design architecture; -by Robert Martin

Rigidity – hard to change

Fragility – unexpected parts of the software breaks.

Immobility – hard to reuse ins another software

5 solid principles; -by Michael Feathers

Single Responsibility Principle - build robust and maintainable software / should have only one (1) reason to change

Open-Closed Principle - easy to change / allow the behavior of those classes to be changed by adding new code

Liskov Substitution Principle – substitutable

Interface Segregation Principle - avoid depending on things that they don’t use.

Dependency Inversion Principle - flexible software / depend on abstract classes or interfaces