Shell Scripting for beginners with a simple example Part 1

This article gives a practical exposure to beginners about shell scripting on UNIX platform. Shell script is a script for the shell command-line interpreter. Shell programming is fun and is used to automate highly repetitive time-consuming manual tasks like environment setup, post processing and configuration value changes that involve file manipulation. We can run shell scripts by installing Cygwin and use Emacs as the editor.

We point to the interpreter (i.e) the shell in the very first line of the script. This is called shebang. #! bin/sh is the default shebang if nothing is mentioned.

Writing a simple Shell Script:

Step1:  In the shell command prompt, navigate to your home directory

sh-3.2$ cd $HOME

cd means change directory. $HOME variable refers to a directory on the operating system containing the user’s files. It can be represented in short using ~ symbol.

Step2:  In the home directory create a new file named date.sh

Step3: Modify the access rights on the file so that you can edit/save it using chmod command.

sh-3.2$ chmod 777 date.sh

Everyone has read, write and execute permissions on the file

sh-3.2$ chmod 755 date.sh

Everyone can read and execute this file but I alone should be able to modify it.

Step 4: Now let us create a simple shell script to display the date and hostname.

We store the hostname value in a variable called HOST. We use the date function to display date in the format %m-%d%-%Y. And echo command is used for displaying/printing the output on the command line.

#! /bin/sh

HOST=$(hostname)

echo “——————————————————————-”

echo “Date:$(date +”%m-%d-%Y”)              Hostname:$HOST

echo “——————————————————————-”

Step 5: Run this shell script using the command ./date.sh from the home directory where you saved it.

OUTPUT:

sh-3.2$ ./date.sh

——————————————————————-

Date:12-14-2010              Hostname:dellwin7-PC

——————————————————————-

Bug prevention – the new definition for software testing

“Bug prevention is the testing’s first goal” – B.Beizer

Beizer stated that “the act of designing tests is one of the most effective bug preventers known,” which extended the definition of testing to error prevention as well as error detection activities. This article gives insight into the power of early testing.

Most of the testers find bugs weeks/months after the designers and developers inject the bug into the product. How many testers proactively engage with their development partners to prevent the bug from ever getting into the product in the first place? If we continue to think of testing as an after-the-development process then our role is nothing more than a bug finder.

To advance our discipline of testing, the testers need to partner with the developers earlier in the lifecycle to move quality upstream and prevent issues. One of the most powerful ways of improving the quality of the product and the team effectiveness is to focus the testing efforts on defect prevention rather than defect detection. This doesn’t negate or eliminate the need for testing. Testing for defect detection alone is like simply treating the symptoms of the problem and ignoring the root cause of the real problem. Defect prevention is about addressing the real problem.

Here are some of the ways for the tester to work in a symbiotic relationship with the developer and move quality upstream:

  1. Participate in code inspection
  2. Engage in design reviews
  3. Prototyping with program manager and designers to prevent sub-optimal designs

Introduction to Test Coverage

 

Test coverage is an indirect measure of quality. It measures how well the test suite actually tests the product. Test coverage analysis helps to find out areas in the program not exercised by the test suite so that we can create additional test cases to cover those gaps. It is a structural testing technique that compares the program behavior against the apparent intention of the source code. It helps finding possible pitfalls in the structure and logic of the program.

There are two broad classifications of coverage measures – Path-based and Fault-based:

Path-based coverage: This requires the execution of a particular component of the program. For example, if the scope of the testing is limited to the payments domain alone, we design the test cases in a way that it fully exercises the payments component of the program

Fault-based coverage: This requires that the test suite exercises a program in a way that reveals all the likely faults. It is used when the test strategy is focused on finding all the defects in a feature irrespective of the components involved.

Test coverage methods:

There are 6 fundamental test coverage methods as below:

Statement coverage: This reports whether each executable statement is encountered by the test suite. It is also referred to as line/segment/basic block coverage.

Decision coverage: This reports whether Boolean expressions tested in control structures are evaluated to both true and false. This is also known as branch/path coverage.

Condition coverage: This reports the true or false outcomes of each boolean sub-expressions separated by logical-OR and logical-AND if they occur

Multiple condition coverage: This reports whether every possible combination of Boolean sub-expression occurs

Function coverage: This reports whether the test suite encountered each function/procedure of the program

Call coverage: This reports whether each function call is executed

Guidelines for writing software test plan

The test plan defines the scope, approach, resources and schedule of the intended testing activities. It identifies the features to be tested, the testing tasks and who will do the tasks.

The three main elements of a test plan are:

  1. Test Coverage: The test coverage measures the proportion of the program exercised by the test suite. It is usually expressed in percentage. It helps in finding areas that are not exercised by the test suite. Having complete test coverage ensures 100% test effectiveness and that the test suite reveals all the defects
  2. Test Methodology: The approach, techniques and tools to be used for testing
  3. Test Responsibilities: Includes the features/functions to be tested and the criteria for success/failure for the tests

The Test Plan contains the following:

  1. The Project Overview
  2. Objective and scope of testing
  3. The test methodology
  4. Resources and responsibilities
  5. The testing efforts and schedule
  6. Entry and exit criteria for testing
  7. The features to be and not to be tested
  8. Success/failure criteria
  9. Test environment
  10. Risk factors and contingency plan
  11. References to the supporting documents which includes FSD, SRS, TDD and the like.

The scheduling of the testing tasks and milestones is done considering the below factors:

  1. Complexity of the feature
  2. Competency of the resource
  3. Stability of the requirements

Each of these factors could be rated as high, medium or low.

For large projects, there will be a single test strategy document. There will be many test plans that draws its content from the test strategy. The Test Strategy is a high level document that defines the testing approach to achieve the testing objectives. It is prepared by the project manager and it will not be updated often. The test plan is derived from Software Requirements Specification, Technical Design Document, and Functional Specification Document. It includes test strategy/test approach as well. It is prepared by the test lead. The test plan needs to be updated often to reflect any deviation from the original plan.

Credit:  Jurvetson (flickr)

If a feature is not to be tested the test plan should state why it is not. For ex: It could be: a low risk feature, tested and found to be stable in the past, not pushed in the current release.

There are several inherent software risk factors in a project like complexity or newness. A well rounded test plan notes all the risks and tasks interdependencies in the test plan and communicates to the stakeholders regarding those dependencies and risks.  Dependencies could be like cross-functional impact of a new feature, delay in getting stable builds, late change in original requirements, late delivery of fix and resource availability.

Once the test plan is documented it requires review and approval by the test manager /release management team in order to move the next phase of testing.

Static testing – early finding of defects

Static testing is the process of evaluating the sanity of the code, algorithm and documents without any execution on computer. It is the only available method to find defects in the early stages of the Software Development Life Cycle. It is completed before the implementation of code.

Static testing can be done through:
1. Walkthrough
2. Inspection
3. Informal Review
4. Technical Review

Walkthrough involves presenting a technical document in a meeting. This is a useful technique to ensure that everyone understands the product. The author of the work product calls for a meeting and presents the product to reviewers, inspection team, engineering leads, managers and other key stakeholders of the product.

Inspection is a well-known software engineering tool to improve the entire development process. In this phase we gather data on the weaknesses in the process and number of hours in correcting them using statistical process control techniques. It is a pre-requisite to reviews. It may be wasteful to do reviews unless the document has successfully exited inspection.

Reviews focus on getting consensus or buy-in to a particular document. Review is the most effective and universal test method. It could be a peer group discussion activity. In this phase the developers can find errors like unreachable code or references to variable that are not initialized. Testers can make sure that the documents (screen design, FSD) are built to standards. Incremental reviews throughout the product construction are essential and profitable method of managing quality.

Review Procedure:
1. What are we testing?

a. Requirements review
b. Feasibility review
c. Review screen layout against standards
d. Analyze program’s control and data flow
e. Existential check of the features expected as a part of the product
f. Review the screen designs, FSD

2. What are the criteria for success?

a. Check for correct and required output
b. Test environment

3. Who will do the work ? (roles & responsibilities)

Key paradigm shift from objects to contracts in the Service-Oriented world

There has been a key paradigm shift from object to contract as the building block for a distributed system in the service-oriented world. Contracts are the new building blocks if we need to develop a long lasting distributed system. How focusing on contracts can improve the business objectives and make partners happier is the least understood aspect of web services which i am going to explain in this article.

There are two common  techniques to develop a web service:

  1. Code-first
  2. Contract-first

Most developers start by writing the service implementation in code and then have a toolkit to produce the WSDL. This approach is called code-first development. Code-first is more common today. This is because working directly with WSDL is extremely difficult. We lack proper tool support to work directly with WSDL and hence code-first is more pleasant. In this technique the developer first codes the logic of how the data is treated within his service. Then he produces the WSDL in an automated way using a toolkit. The WSDL thus produced contains language-specific types. When the business partner wants to interact with the service contract, he realizes that his application doesn’t map nicely to the service contract coded by the developer as it contains language-specific types and he starts looking elsewhere for the service. The key principle of Service Oriented Architecture is to ensure ease-to-consume a contract. The Code-first approach is technology independent and lacks ease-of use.

The fundamental goal of the Contract-first model is to facilitate interoperability. The reach of a web service is unlimited. Embracing this new model of contract-first ensures happier partners. In this approach, the developer first codes the standard contracts that will be shared with the partners. Here the developer focuses on how the data is moved across service boundaries rather than within the service. He invests a lot of time and energy in contract design. He first codes the XML Schema and WSDL definitions. After everyone agrees on WSDL he implements the code. This approach embraces service orientation and is disconnected from how you treat data within a service. It is focused on connecting the dots within a distributed system as a whole. Ease-of use of the service is under the control of contract definition. The Contract definition is a shared language which is the primary focus of this model. This approach ensures that the service designed is interoperable across a wide range of platforms, operating systems and programming languages. It helps partner collaboration and meets the enterprise goals.

Top down vs bottom up SOA

This article compares the two approaches of web services development - top-down and bottom-up - as the battle between the purist versus the pragmatist, the value generator versus the cost saver and the Business Evangelist vs IT implementer.

Web services can be created using two methods: top-down development and bottom-up development. Top-down web services development involves creating a web service from a WSDL file. By creating the WSDL file first you will ultimately have more control over the web service. When creating a web service using a top-down approach, first you design the implementation of the web service by creating a WSDL file.When creating a web service using a bottom-up approach, first you create a Java bean or EJB bean and then use the web services wizard to create the WSDL file and Web service.

appraoch

Should a top-down business-centric approach or a bottom-up approach be employed given that the Business Unit (BU) is more reactive and sensitive to the realities of IT?

The Model-Driven Architecture (MDA) provides an approach aimed at achieving technology independency through full top-down development. In top-down approach the WSDL is designed from a business point of view and is not driven by a service consumer or an existing application. The “WSDL to Java” tool generates java code according to JAX-RPC or JAX-WS. These classes can then adapt the existing business logic.

Although bottom-up Web service development may be faster and easier, especially if you are new to Web services, the top-down approach is the recommended way of creating a Web service. The bottom up approach generates web services for which the design is driven from an application point of view (developer driven) and will not address the need for other consumers.