System Security & Controls on IDs and Passwords (Bank Level Security)

The tips and tools in this check list can help secure your system for system .

  • The input field for password MUST be masked while the users type in their passwords.
  • Password history can be configured and set minimum 3 generations. User cannot change password similar to previous password.
  • Password expiration can be configure and set to 60 days. System must enforce change password automatically every 60 days.
  • Minimum password length is 8 characters. (Recommend 8 characters).
  • Password MUST force to change on the first sign-on.
  • Account lockout can be configured. After 3 consecutive unsuccessful attempts, the user id must be locked.
  • Password must meet complexity requirements which include numbers, symbols and both upper or lowercase alphabet characters. Password composition must include at least 1 number, 1 special character, 1 upper and 1 lower case alphabet characters.
  • Users are allowed to change password without administrator assistance.
  • Dormant period can be configured. IDs that have been dormant or inactive for 30 days will be automatically revoked.
  • Users are not allowed to sign-on to more than one terminal at a time. Users must log-off from one terminal in order to sign-on another terminal.
  • The system must display the last sign-on information after a successful sign-on.
  • User IDs which are inactive for 15 minutes must be logged-off from the system.
  • Users are not allowed to use password to be same as their ID.
  • System must facilitate the admin by providing a list of inactive ID for more than 90 days or script for deletion.
  • Restriction of access using specified date and time is allowed where applicable.
  • Multi-level of access is allowed.
  • A warning statement on misuse computer information and facilities must be displayed:
    • Upon successful login to a system, or
    • Just before the login prompt to a system, or
    • On the same screen that provided the login to a system.

Software Testing (Definitions and Terms) – part 2

Baseline

A baseline is defined as a single set of data that has been captured for purposes of measuring improvement.

A baseline is a set of captured data to measure improvement. A baseline can be a benchmark, but a benchmark can only be a baseline once. A baseline is generally is generally captured once during a cycle or phase, and future benchmarks are compared to a single baseline.

Methodology

A methodology is a defined set of methods collected to accomplish a goal.

methodology

methodology

In many organizations, the term methodology is commonly used when describing the ways actions are done in the company. These actions are typically executed with certain methods or ways of doing things. Over time, organizations learn from their mistakes and modify these methods, formalize them, and call them their methodology. These collections of methods are often revisited and improved over time.

Process

A process, in terms of software methodology, is a set of related tasks which are compiled to a accomplish a goal.

process

process

Within a methodology, each method defined generally requires a set of tasks that must be completed. These set tasks are called processes. Both a methodology and it’s encompassing processes are created to accomplish a common goal for the organization.

Procedure

A procedure is a set of actions, operations, or methods which are executed the same way each time in order to obtain the same result.

procedure

procedure

Procedures exist within the methodology  to ensure the processes are executed in a consistent manner. These set of steps are defined to complete several tasks to complete certain processes which make up a methodology.

Test Framework

A test framework is a set of concepts, methodologies and tools to support the software testing effort.

test framework

test framework

Test frameworks provide a mechanism for consistent testing procedures around software testing. These repeatable techniques ensure the software testing practices yield reliable results as the organizations matures.

Keyword-driven Testing

Keyword-driven testing is a test methodology which employs action-words to drive events in a test case or script.

keyword-driven testing

keyword-driven testing

As organizations become more test savvy, a methodology known as keyword-driven testing provides an effective mechanism to organize the test scripts into logical components that can be used repeatedly. These components typically consist of an object, an action, and supporting data if required. The methodology usually requires a longer ramp-up period since planning and implementation of the components take time to build and organize. This initial investment pays off since there is an substantial decrease in technical skill requirement to build keyword-driven tests once a framework is in place.

Verification and Validation

verification and validation

verification and validation

Two terms that are commonly used in the software testing world are verification and validation.

Verification is a quality process which ensures a product complies with standards and regulations. Validation on the other hand, ensures the product adheres to established requirements. A quote from Barry Boehm makes this clear; Verification ensures we are producing the product right and Validation ensures we are producing the right product.

Software Testing (Definitions and Terms) – part 1

Use Case

A use case is a technique to capture the functional requirements of a system. It uses actors/roles and events to represent business functionality.

use case

use case

Use cases provide a description of interaction between business roles and the system under test. Use cases utilize “actors” to represent the initiator role which interacts with the system. These actors can be end users, other systems, or hardware. A use case shows a series of events or actions which are executed by the actor. From a software testing perspective, use cases provide a firm foundation for how tests should be designed to validate business functionality.

Test Case

A test case is a set of conditions and variables built to determine if software meets expected criteria.

test case

test case

Traditional test cases are built from formal software requirements and are used to measure if the product meets the business needs. The most optimal situation calls for test cases to built from established use cases in order to cover business flows of the software.

Test Script

Test scripts are test cases are manual or automated.

test script

test script

A test script is often interchanged with the term test case in many organizations. The differentiator with test scripts is that they can be manual or automated tests. Software testing organizations generally dedicate particular testers to develop automation testing programs which are called test scripts.

Test Suite

A test suite, or validation suite, is a collection of test cases designed to conduct and validate a business process.

test suite

test suite

The concept of a test suite arises when testers feel a need to combine several test cases in order to complete a business process (also known as a business function). Software testers use the results of these test suites to report the stability of business processes. Test suites are an important component of a software tester’s arsenal.

Defects

A software defect is generally defined as a discrepancy between established software requirements and software functionality.

defect

defect

Software issues are commonly referred to as defects. From a software testing perspective, a defect is loosely defined as a discrepancy between software requirements and software functionality. There can be many types of defects other than those related to testing. For example, a software requirement can not match the needs of the business and it would generate a defect in the requirements. Defects are often managed in a defect management system that allows developers and testers to enter, assign and prfioritize them. These systems can also generate reports to measure the quality state of the software.

Benchmark

A benchmark is a standard by which something is evaluated or measured.

benchmark

benchmark

A benchmark in the SDLC consists of measuring a set of activities or data in order to determine improvement. An example of a benchmark is the STLC is taking a snapshot of the number of critical defects within software build. The benchmark could determine if future software builds are better or worse than the one measured.

Reference: Introduction to Testing, HP Software University Student Guide.

Introduction to Software Testing

What is Software Testing?

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. http://en.wikipedia.org/wiki/Software_testing

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. http://users.ece.cmu.edu/~koopman/des_s99/sw_testing/

In general, software  testing verifies that software behaves according to a predefined set of requirements. For example, if an application is defined to search for a term on the internet, a software test would verify the appropriate search results are returned. Software testing is a process. It is a methodical series of techniques to ensure quality and repeatability.

Who typically does software testing?

  • Software developers
  • End Users
  • Business Analysts
  • Support Staff

In some organizations, two groups perform software testing. Software developers and end users.

  • Software developers are the writers of the software program and understand the inner-workings. They typically validate their area of expertise and the “code” level using basic sanity testing.
  • Business Analysts are individuals who are familiar with the business processes (or business functions) and tend to validate the business needs are met with the software from their perspective.
  • End users are the users of the software. They use the software for day-to-day activities and “test” the application simply by using it for its purpose. If an issue or discrepancy is found in the software, in the end users would report it and solicit feedback through various mechanisms.
  • Support staff are responsible for supporting the end users and/or customers. They report issues found by end users and customers through various feedback mechanisms and also provide valuable feedback on steps to reproduce.

Who should do software testing?

Software testing, like software development, is a profession.

  • Software testers employ unique skill sets to ensure software quality
  • Certifications level were created by the International Software Testing Qualifications Board (ISTQB)

If developers end users test based on their own needs, who’s going to represent the business? Who is going to make sure the business requirements are met? Who is going to manage and mitigate risk when it occurs? The answer it software testers.

Software testers should have some technical skill coupled with a business mentality. To perform testing the right way (not through trial and error), it requires time and money. Time and money are not always readily available to a majority of companies.

software testing

software testing

Reference: Introduction to Testing, HP Software University Student Guide.