2009-Mar-7 - OOP languages and concepts

OOP concepts:

• encapsulation - Conceals the functional details of a class*.
• modularity - Simple parts connected by clean interface.
• polymorphism** - Different data types respond to methods of same name
• inheritance - Subclass, specialized version of class.

*Class - abstract characteristics of a thing (object)

  Object - pattern of a class

  Instance - actual object created at runtime

  Multiple inheritance - one subclass has more than one superclass

 

**Polymorphism:

• Override - Child-class overwrites parent-class function (NOT private)
• Overload - Functions with same name, but different parameters (type / number / order) (NOT private in parent)

If a function would have different behavior in subclasses, it should be virtual.

If a superclass (base class) has a virtual function, it should be overridden.

OOP languages: C++, Java, Python, Perl ...

	C++/Java	Python	Perl
integers	primitive native types	objects (of int class)	treated as double float
self pointer	this	self	(any)
constructor	classname()	__init__	NEW
destructor	~classname()	__del__	DESTROY
class members	public, private, protected	all public	all public
methods**	public, private, protected	all virtual	all virtual
private variable	private xxx;	__privatevar	all public*
pass by value/reference	C passes by value; Java passes references to objects by value.	Passes references to objects by value.***	Pass by reference - hard / symbolic

* Perl coding convention: use _ or __ (double underscore) before variable to indicate private. But not enforced.

** Subroutine:

• function: "return xx;"
• procedure: no return. Sometimes synonymous with function, eg. in C.
• method: OOP concept, part of objects

*** Python 2 kinds of data structure:

Immutable: string, tuple

Mutable: list, dictionary

 

2009-Mar-7 - Mail / FTP / HTTP protocols basis

SMTP:

Commands:

one session:

HELO

MAIL FROM: <...>

RCPT TO: <...>

(RCPT TO: <...>)

DATA

...

.

QUIT

Other commands: RSET, NOOP

Response: 1xx, 2xx, 3xx, 4xx, 5xx

POP3:

Commands: USER, PASS, STAT, LIST, RETR, DELE, NOOP, RSET, QUIT, TOP msg n

Response: +OK, -ERR

IMAP vs. POP3:

IMAP:

• Client does not download the whole mail, only downloads the mail header.
• Client can directly manipulate the mails on server.
• User can maintain the mail directory on server.
• User can retrieve specific part of a mail, eg. text.  

FTP:

Commands: USER, PASS, RETR, TYPE (A/E/I/L), PASV, STOR, DELE, LIST, PWD, NOOP, QUIT, CWD

Response: 1xx, 2xx, 3xx, 4xx, 5xx

HTTP:

Simple:  GET URI HTTP/version

Full:

(General-Header                  - Date / Pragma

 Request-Header                  - From / If-Modified-Since / Referer / User-Agent

 Entity-Header)                     - Content-Encoding / Content-Length / Content-type /

                                               Expires / Last-Modified

 CRLF

[Entity-Body]                       *OCTET

Response:

1xx     informational

2xx     successful

3xx     redirection

4xx     client error

5xx     server error

		Servers	Clients
HTTP	Windows	IIS; Apache	IE; FireFox; Netscape; Mozilla
	Linux	Apache	FireFox; Netscape; Mozilla
FTP	Windows	IIS; ServU	WSFTP; CuteFTP; FFFTP; FlashFTP; SmartFTP
	Linux	proftpd	(command line)
Mail	Windows	IIS; MS Exchange; KerioMailServer	MS Outlook; Outlook Express; Foxmail; Eudora
	Linux	Postfix	(command line)
Proxy	Windows	CCProxy	/
	Linux	squid	/

2009-Mar-7 - Test Plan framework

Generic Test Plan:

1. Reference Documents (Requirements)

*2. Objective (Prioritize functionality / usability / reliability /security / stability / sustainability / portability / efficiency ...)

*3. Scope / Test types (and pass criteria)[1]

4. Test environment (software / hardware / network / other facilities)

5. Test tools

6. Human resources (team member vs. responsibilities)

*7. Schedule

8. Bug priority / severity definition

*9. Alpha / Beta / release criteria

10. Risk analysis (mitigation plan)

* I consider must-have.

[1] Test types:

• Functional test - normal, boundary, force error
• System test - compatibility, conformance (standard), integration, volume / load (performance / stress), I18N / L10N, security, stability test
• Coverage test

Performance Test Plan:

1. Objectvie /Goals (requirement, pass / fail criteria)

2. Navigations (business process, prioritize)

3. Scenarios (min / max / ave. load)

4. Environment

5. Monitors (measurements)

6. Schedule

7. Resources

8. Risks

2009-Mar-7 - My tool kit

UI test tools:

     QuickTest Pro (QTP)

     IE7 Readiness Toolkit -- for IE7 compatibility test

     Sprajax -- assesses the security of AJAX-enabled web applications

     Rational Robot

Installation test tools:

     InCtrl5 (windows) -- monitors the changes made to the system

     SciTe for AutoIt (windows) -- auto-installation

Resource leak test tools:

     Valgrind (linux) -- memory leak, etc.

     Rational Purify (windows) -- memory leak

Stress test tools:

    Canned HEAT (CH3) (windows)

    stress-0.18.9 (linux) -- stress on cpu, memory, disk space, etc. 

Test Coverage tools:

     Bullseye (windows / linux)

     Cobertura -- based on jcoverage. Used for java program.

     Rational PureCoverage (windows)

Performance test tools:

     Jmeter (windows / linux) -- open source.

     LoadRunner (windows)

Security test tools:

     IDS test tools -- IdsTest (linux), Hping (linux), netwox (windows)

     Security QA toolbar -- SQL injection, LDAP injection, XPATH injection...

Fuzzing test tools:

     JBroFuzz

     Webscarab

     Suru

     Sulley

Web app test tools:

     WebInject

     curl (linux)

     MS Web Application Stress Tool

     Security QA toolbar

System monitors:

     CurrPorts (windows) -- list of opened ports and the processes.

     Informer (windows) -- reports system status.

     TCPView (windows) -- list of running processes and more details.

Data capturers:

     HttpWatch

     Sniffer pro (WireShark)

Test cases optimizing tools:

     allpairs -- constructs a reasonably small set of test cases that include all pairings of each value of each of a set of parameters. Supports diagnostic output.

     pict -- similar to allpairs. Supports sophisticated options.

Remote control:

     PsTools (windows) -- PsExec: execute programs on remote systems; PsFile: shows / closes a list of files on a system that are opened remotely; etc.

     Remote Administrator (windows)

     Remote Desktop (windows)

     Putty (linux), Pietty (linux, cn / jp locale) 

     SSH

Test Automation Framework:

     STAF

Installshield:

     PackageForTheWeb -- e.g. pack a hotfix

     IExpress

Project management:

     WBS + PERT + MS Project

     WBS -- for constructing plan and schedule

     PERT -- for estimating most possible ending date

     Project -- for making project plan, tracing and controling progress

Virtual Machine:

     VMWare (VMWare)

     Virtual PC (Microsoft)

     VirtualBox (Sun)

Source code control:

     SVN (Subversion)

2009-Feb-28 - New start in a big pond

 It's been 3 months now since I joined a new company. I’m still getting used to it. I mean, there are so many differences between working as a QA in an SMB like my previous company, and a huge enterprise like my current employer.

1. New hire guidance

In my previous company, which is much smaller, they are able to provide a clear list of “What to do” for new hire, like whom you should contact if you are in some situation, or where you can seek help when you are in some another situation.

My current employer provided a first day orientation, which propagandized company culture, and gave us a website, which surely contains all the information we need yet it’s too huge. My direct manager did most of the other orientation job afterwards, but some information he provided was either outdated or conflicted with what HR said later. I was confused sometimes, trying hard to figure them out myself.

2. Organization

My previous company is simpler, from director, to XXX managers, to developers and QA engineers, straightforward, and people know each other. One RD team works on one project, developers program and QAs test.

My current employer is much more complicated. Different kinds of teams, different kinds of roles, even QA has several categories, focusing on different kinds of testing on the same project. I always wonder if we will miss anything in the cracks between these QA teams. 

3. Process

The previous company has an SQA team that supervises the product development cycle to make sure it adheres to process. They involve in requirement review, design review, plan review, and then after release, they analyze the testing data and do postmortem.

Now we do not have this kind of force in my company. We are working on many small releases of old products, and have short time span and not very strict process. No hard test coverage requirement, how many tests to do depend on QA’s experience and developer’s suggestion. Bug priority at 3 or lower are sometimes ignored, and product goes on releasing. Usability, UI, comprehensive messages are not a bit in consideration. Nobody cares about that because there are so many projects on one’s hand at the same time.

4. Culture

In my previous small company, employees’ race, age, experience, and even character are close. We worked together, played games together, and even rent an apartment and lived together. It’s pretty simple, and people like each other.

In a big old company like the one I’m in today, we have so many colleagues from different countries, in different age, and have different experiences. People do not hang out a lot after work. They don’t see each other even working on the same floor. They prefer conference call than physical show up. In a team meeting, if one’s not aggressive enough, he would have no chance to chip in, because there always are talkative members out there that really show they are involved.

The good thing is, in a big company, you always have something new to learn, either from projects, or from the coworkers.