Ally's a QA

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

 

Comments (0) :: Permanent Link

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 /

 

Comments (0) :: Permanent Link

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

Comments (0) :: Permanent Link

2009-Mar-7 - My tool kit

Posted in My tools

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)

 

Comments (0) :: Permanent Link

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

Posted in My thinkings

 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.

 

  1. 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. 

 

  1. 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.

 

  1. 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.

 

Comments (0) :: Permanent Link

<- Last Page :: Next Page ->

About Me

Here I share my experiences and thoughts as a QA engineer, and a place to put my notes.

Search This Blog

Categories

My thinkings
My knowledge base
My tools

Links

Home
View my profile
Archives
Friends
Email Me

Friends

whollymindless
strazzerj
syed1982
mferris
ukkuru
michaeljf
agvasqa
priyabala
srini847
spikyone
naba123
Blog Widget by LinkWithin