Return from Holidays

Last week was full of fun with no access to any computer ( mobile phones are exception). Hence there were no posts on this blog. I am still going through all my emails and other electronic stuff.

XSS vulnerabilities in flash files

Websecurity.com.ua has post describing XSS vulnerabilities in flash files. Article XSS vulnerabilities in 8 millions flash files discusses how Action Scripts used in flash are vulnerable. Fount it as a nice read.

Read original article at: XSS vulnerabilities in 8 millions flash files

Bash shell logging technique

In my previous post, Record command lines / terminal sessions on UNIX shell, we have seen the use of ‘script’ CLI to record terminal session on Unix (LINUX) platforms.

There are few other ways to monitor or logging user shell using rootsh, sudosh and ttyrec etc. However, in this post, we will utilize ‘script’ CLI to monitor or logging user’s command line shell. This is useful if you are hesitant to install any third party tool on your Unix box which is often a case in production environments.

It is fairly easy to invoke ‘script’ after user logs in. Just put following entry (colored in orange) in ‘/etc/profile’ file.

--------------------------Start Of Shell------------------------------------
ts:~# tail /etc/profile
            test -x /usr/bin/faillog && /usr/bin/faillog
        fi
    fi
esac

/usr/bin/script –a  /path/to/your/$USER.txt 2>&1
exit
#
# End of /etc/profile
#
ts:~#
--------------------------End Of Shell------------------------------------

Above Two lines at the end of ‘/etc/profile’ invokes ‘script’ CLI immediately after user logs into the machine and redirecting its logged shell output to “/path/to/your/<YourUserName>.txt” file. So whatever user types or displayed at the shell prompt (terminal session) is logged automatically by default.

Be careful while utilizing this technique as once you log out and again login to the machine, your session will also get recorded immediately. So path to the file where terminal session is recorded should be carefully chosen and secured. Path specified above is for example purpose only. Considering this technique is also useful for spying or logging user shell or terminal sessions without requiring any third party tools, people securing their UNIX machines should take note of this point.

Do you use any other method to log your shell? Do let everyone know in comments below.

Record command lines / terminal sessions on UNIX shell

Most of the IT professionals often need to record whatever is displayed on their windows screen using different video recording tools. However, when comes to different UNIX (LINUX, Solaris, AIX etc…) environments, sometimes it is not possible to just rely on history command output from terminal session. As history doesn’t record terminal session output of CLIs that we executed. (I am not referring to putty sessions which can also be recorded from windows using free video recording tools).

This post tries to dig into one of the known ways, but often ignored, for recording terminal session or command lines on UNIX shell.

# script test.txt
Script started, file is test.txt
# echo Hi
Hi
# echo This is a script recording.
This is a script recording.
# exit

Above ‘script’ CLI when invoked starts shell recording into test.txt file. Now ‘test.txt’ file contains all the commands or CLIs along with their output that we executed in terminal session. Below is output of ‘cat’ CLI.

# cat test.txt
Script started on Tue Dec 15 15:48:13 2009
# echo Hi
Hi
# echo This is a script recording.
This is a script recording.
# exit

Script done on Tue Dec 15 15:48:39 2009
#

However, if default shell is other than ‘sh’ then “test.txt” might contain ^M characters as below.

# vi test.txt
Script started on Tue Dec 15 15:48:13 2009
^[[?1034h^[[1m^[[31m # ^[(B^[[mecho Hi^M
Hi^M
^[[1m^[[31m # ^[(B^[[mecho This is a script recodr^H^[[K^H^[[Krding.^M
This is a script recording.^M
^[[1m^[[31m # ^[(B^[[mexit^M

Script done on Tue Dec 15 15:48:39 2009
#

Hence, ‘script’ CLI works best in environments when there is little manipulation of STDOUT. However, this can easily filtered out using ‘sed’.

In next post, we will see how to use script CLI to verbosely log all terminal session activities by default.

Effective Test Cases

Often a question arise of writing effective test cases in software testing. Though writing test cases can be a easy task for SQA, it is often hard to believe that whether these are overall effective test cases. Though my previous post, Effective Software Testing in 10 steps, covers effective software testing as a broad idea, this post concentrates on guidelines for writing effective test cases.

+ Stick to software design specifications while deriving test cases.  In case where design specifications are not available, work closely with respective developer. This should cover all functional test cases.

+ Start with basic or easy inputs. Try to work out product functionality first. Then go for more complex set of inputs.

+ For every test case define pre-condition

+ It would be good to write test cases as series of events rather than creating independent test cases. This will also ensure smooth workflow of events as a part of testing.

+ Try to amalgamate multiple test cases into single test cases if possible.

+ Automate as many test cases as possible. If possible and also makes sense then automate multiple test cases into a single automated test script. IMO there is no rule that states one-on-one mapping of test cases to automated test scripts.

If you have more suggestions for making test cases more effective then let everyone know in comments below.

Effective Software Testing in 10 steps

I was thinking about product testing that can be performed more effectively. And here are 10 guidelines that I come up with for effective software testing. These guidelines are of course applicable once product arrives for testing. :)

1. Get the product’s domain knowledge E.g. if product under test is a web application then tester should know about web server, CGI, etc. If product under test supports Solaris zones then tester should know types of zones and how they work etc. This will help tester come up with different test cases.
2. Ensure that tester has all insights of test-bed. This will ensure that tester understands the environment where product will be tested. Sometimes changing system parameters (on test-bed) can severely affect product.
3. Define Test plan for ultimate goal of testing. E.g. test plan should state clearly if tests requires white box testing along with black box testing.
4. It is also important that test plan states overall scope of test cycle (I am not covering all granularities of test plan). Scope should cover different types of testing that can be performed over entire product testing cycle.
5. Develop test cases to cover all functionality of product under test. It is always helpful to get inputs from developer who has developed the feature while coming up with different test cases. Ensure that negative test cases are also covered along functional test cases.  E.g. In case of network application what if there is loss in network connection? Does application crash due to sudden network disruptions?
6. Never ignore security test cases.
7. Keep all matrices in hand to measure continued progress of software testing. This should not be the only task of Test Leads or Managers. A tester should measure his individual performance to fine tune his performance. Graphical representation of these matrices using simple tools such as excel will provide a helpful insight.
8. Automate as many test cases as possible if feature is well stabilized. Freeze on automation tool well in advance that will be used by all team members. It will be helpful to include name of automation tool in test plan itself. Tester should not try to automate a feature which is under development ( Not valid in case of unit testing). Due to constant changes during development of a particular feature, it wouldn’t make any sense to automate test cases and waste valuable time.
9. While executing performance testing cycle, get all the numbers in advance for a product under test. E.g. during load testing what will be the maximum load (e.g. number of users allowed) that application can handle, should be known in advance. During stress testing, ensure that exact breaking point of application is noted.
10. Compatibility testing is also important and should be aligned with environment where customer will possibly deploy the product.

Though above guidelines do not cover each and every aspect of software testing, still it provides broad picture of what needs to be done. Do you have any more inputs to add then let everyone know in comments below.