Thinking Software Testing

The primary goal of testing is to improve Quality of end product. No! No! I am not saying its only responsibility of (quality) engineers. Rather I feel that it is a collaborative job where every individual working on any piece of software at hand is responsible for end product / outcome. This individual could be program manager or product manager (some organizations may have both mixed with single role / title) who is managing release program or software development engineer who is writing a code or software quality engineer who is verifying/testing the code or document writers working on product documentation. The best analogy that I can think of is aircraft. If any one of the functions that we described (as example) in above roles does not produce quality outcome then aircraft may never fly due to prolong delays or it may malfunction immediately before/after takeoff or after prolong operation in air :) or incorrect documentation that may create trouble while flying. The later three are bit scary!!!

Every individual who is part of product release should strive to maintain quality of outcome in his own capacity with strict controls. Controls that ensure quality from different perspectives. I could think of different perspectives by answering following questions,

1. Customer 
- How easily customer can deploy our software product? How smooth is upgrade process in case of new release?
- After installation, how much time does our software product take to become fully functional? Does it preserve previous customer configuration and works as expected?
- How easy to configure our software product?
- How many features does customer really needs?
- How our software product/outcome will be used and in which environment?
- What are different software product configurations customers may deploy?
- How much stress will be applied to each of the software product configuration in customer environment?
- Is there any proactive mechanism in place to alert customer of possible near-time issues/problems with deployed configuration?
- How much cost savings customer brings in if s/he decides deploys our software product?
- Does software function as it is intended to function over prolonged and continuous usages in all supported configurations?
- Does our software product cause downtime to itself and any other products in its ecosystem?

2. Engineering
- Does software product undergo full functional testing?
- What are the domains of expertise needed to test our product? If there are no in-house expertise or subject matter experts not available then how to bring expertise to test the product?
- What are the different customer problems that our software product solves?
- What are the ideal performance numbers in terms of load testing and stress testing?
- Are these performance numbers are documented in product documentation?
- Do any of the new features have caused possible regressions?
- How much automation is in place to identify regressions as quickly as possible and to speedup the testing process in future releases?
- How agile is overall development process?
- Does change control mechanism is in place?
- Does software test repository is actively maintained and tracked?
- What should be the ideal functional and conditional code coverage?
- What is the mechanism to deliver a fix if there is critical bug found while in-house testing after product is generally available (GA) or at customer site?
- What should be the ideal response time to deliver critical fixes?

3. Market
- What are the advantages (features) over other competing software products?
- Does this release time the market or is it really needed?

I have added market perspective above because I feel that if software product does not sell then it is very difficult to prove that it is a quality product. :) I am sure that there are many other areas that are left untouched. Feel free to add your comments that stimulate thinking in testing.

HP-UX disk multipathing health status

Sometimes it is required not only to monitor disks/luns attached to machine but also status of those disks. Status of disks means the path available to disks/LUNS e.g say disk/LUN "A" and how many paths to disk/LUN "A".

Below CLI lists disks attached to HP-UX machine,

bash-2.05b# ioscan -fnC disk
Class     I  H/W Path  Driver S/W State   H/W Type     Description
==================================================================
disk      0  0/0/0/2/0/0/0.0.0              sdisk   CLAIMED     DEVICE       HP      LOGICAL VOLUME
  /dev/dsk/c0t0d0     /dev/dsk/c0t0d0s1   /dev/dsk/c0t0d0s2   /dev/dsk/c0t0d0s3   /dev/rdsk/c0t0d0    /dev/rdsk/c0t0d0s1  /dev/rdsk/c0t0d0s2  /dev/rdsk/c0t0d0s3
disk     13  0/0/0/5/0/0/0.2.16.255.0.0.0   sdisk   CLAIMED     DEVICE    XXX     XXX
                      /dev/dsk/c3t0d0   /dev/rdsk/c3t0d0
disk     14  0/0/0/5/0/0/0.2.16.255.0.0.1   sdisk   CLAIMED     DEVICE    XXX     XXX
                      /dev/dsk/c3t0d1   /dev/rdsk/c3t0d1
disk     15  0/0/0/5/0/0/0.2.16.255.0.0.2   sdisk   CLAIMED     DEVICE    XXX     XXX
                      /dev/dsk/c3t0d2   /dev/rdsk/c3t0d2
disk     16  0/0/0/5/0/0/0.2.16.255.0.0.3   sdisk   CLAIMED     DEVICE    XXX     XXX
                      /dev/dsk/c3t0d3   /dev/rdsk/c3t0d3

.
.
.

Mapping to legacy DSF to that of persistent DSF is already covered in one of the older posts, HP-UX disk mapping between persistent and legacy DSF

Now in order to view health of all LUNS we can use same ioscan CLI,

bash-2.05b# ioscan -P health -C disk
Class     I  H/W Path  health
===============================
disk     23  64000/0xfa00/0x1   online
disk     24  64000/0xfa00/0x3   online
disk     25  64000/0xfa00/0x4   online
disk     26  64000/0xfa00/0x5   online
.
.
.

Now considering there are multiple paths to the LUNS their status is equally important for high availability of data. To get the status of all lunpaths to the disks or luns attached to the HP-UX server we will use same ioscan CLI with slightly different syntax,

bash-2.05b# ioscan -P health -C lunpath
Class     I  H/W Path  health
===============================
lunpath   0  0/0/0/2/0/0/0.0x0.0x0  online
lunpath   1  0/0/0/2/0/0/0.0x0.0x4000000000000000  online
lunpath  16  0/0/0/5/0/0/0.0x5000097408159d20.0x0  online
lunpath  21  0/0/0/5/0/0/0.0x5000097408159d20.0x1000000000000  online
lunpath  22  0/0/0/5/0/0/0.0x5000097408159d20.0x2000000000000  online
lunpath  23  0/0/0/5/0/0/0.0x5000097408159d20.0x3000000000000  online.
.
.
.

We can observe that status of lunpath is online. For more status strings check out ioscan man page.
 

"perl: warning: Setting locale failed." : Solved : How To?

I have started receiving perl locale warnings despite LC_CTYPE was set to "en_IN" . Don't know what triggered it on my machine!
Every perl script call was emitting these locale warnings.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = (unset),
    LC_ALL = (unset),
    LC_CTYPE = "UTF-8",
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Well I know there are different ways to solve this problem based on different distribution to make it work. But frankly the easiest and classic way is to add below entries into /etc/profile

export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8   

Another way could be ,
echo “LC_ALL=en_US.UTF-8 ” >> /etc/default/locale

If wondering which locale to add then below CLI will list all supported locale on linux box,

$ locale -a
C
C.UTF-8
de_CH.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
zh_CN.utf8
zh_SG.utf8

Will it cause any repercussions? I don't know. But aleast on my machine this solved the problem and stopped giving "perl: warning: Setting locale failed." warning messages and till now everything seems to be going fine.

dbprofile to boot from Ignite Server

It is always convenient  to install different Integrity VM (s) or vPar (s) from Ignite server and sometimes (there could be many situations) virtual machines or vPars do not receive IP address from Ignite server.

To proceed in such situations, boot machine (could be virtual) and change to EFI shell and create "dbprofile"

shell> dbprofile -dn -sip -gip -cip -m -b "/opt/ignite/bin/nbp.efi"

This will create dbprofile entry with name .
Now in order to proceed with installation, use following CLI from same shell prompt as below...

shell>lanboot -dn

And voila! Installation proceeds. 
That is it for today.

WWN on AIX: How To?

Below are the commands used to identify WWNs on AIX,
#lsdev -Cc adapter | grep -i fcs
Above CLI will list all HBAs (FC port) detected by AIX. Lets say from the output we determine one of the FCs as fcs0
#lscfg -vpi fcs0 
This CLI will display all information about fcs0. If we want specific information about WWN then we can easily grep the output of above CLI as below,
#lscfg -vi fcs0 | grep -i Network