2008-Jan-26 - Making it Agile

To avoid becoming more and more conservative in releasing our product, the executives ordered that we introduced Agile mentality, and made our software development AGILE!

Well, before that, we do not have any clue about what Agile is, neither we have a successful agile pilot team. So we, the development group, started whitehanded.

Does it mean shorter schedule, no documentation, less test...?

After a couple of weeks of study and discussion, we found some difficulties in implementing Agile process (maybe it's not called a process for Agile) from our engineers' point of view. And the top 3 are:

1. Instant face to face communication among all stakeholders are not possible.

Because we are a transnational company, and the stakehoders, i.e. marketing team, development team, sales, tech writers, decision making managers, etc. are locating through out the world in different time zones.

2. Lack of senior, experienced engineers.

All developers and QAs in our team have only 2~5 years software development experiences. And nobody have ever involved in an agile team. 

3. Working model is not decided yet a new cycle of product development is on the road.

We have started our new version of product development, but how to work agile is still in discussion.

I will follow up what happen on our agile development in my coming blogs.

2008-Jan-3 - Checkpoints for program uninstallation

1) Program files and folders.

2) Program related registry entries (regedit).

3) Related processes (task manager).

4) Related services (services.msc).

5) Shortcuts on desktop, Start menu, Quick Launch, and any other places in which may have shortcuts added during installation.

6) Program name in Add or Remove Programs in Control Panel.
7) Items added in OS settings. For example,
(a) Windows firewall exception list, including program name and service name in advanced settings.
(b) Services added in Local Area Connection Properties.

The best thing to do is to ask the developer for a list for What is Done during installation, then check one by one after uninstallation for what has been left.

2007-Dec-5 - QA career path again - a chance for me

The project I had been doing was suddently announced STOP yesterday. It was a big shock for most of the engineers in our team because it was the first time for many of us to encounter termination of a project during construction phase. Managements comforted us saying that it was a great chance for us to change to something we really wanted to do. Since our team had been working on this project (different versions) for almost 3 years, now it finally gives us a break to get a good think about our path and choice.
I consider this a big chance for me to expand my skills for QA career. So I first of all list my advantages and shortcomings.

Experienced:
Gateway product testing (protocols: FTP/SMTP/POP3, and a little HTTP)
Blackbox testing (execution, case design, and bug reporting)
Functional testing, integration testing, system testing, regression testing
Document review
Manual and automation testing
UI testing, installation testing
Automation tools: QTP, AutoIt, and others (http://www.sqablogs.com/ally/1113/My+tool+kit.html)
Windows and Linux application testing
Network knowledge (CCNA certified)
Globalization testing (internationalization & localization)
Post-sale product sustenance

Little experienced:
Scripts: VB, Perl
Mentoring interns

No clue:
Web application
Database application (SQL, Oracle)
Performance test

Now it's clear for me what skills I need to put on - Web/database application testing, performance testing, more scripting and automation experience, and more project experience. And of course, for long term, I will also learn to write test plans, create strategies and schedules, analyse testing effectiveness from various testing data. I will choose a project that can help me to gain these skills.

2007-Nov-23 - Lessons learned from the last project

Hooray! Another project is coming to the release day next week!

Some lessons can be learned from the last phase of the project, especially some points I missed in my test design and execution, which resulted in some bugs were not found in earlier phase.

1. Checkpoints of product name change.

Our product name has been changed during beta phase due to legal issues. Here is the checklist of the possible places contained product name:

1) File name, including shortcut name.

2) Registry

3) Process name

4) Service name

5) Windows title (web/win32)

6) Text in message boxes, web console, command line, and other UI.

7) All documents (Guide, readme, online-help, usage prompted in command line, etc.)

8) Items added in OS settings. For example, Windows firewall exception list, including program name and service name in advanced settings.

#8 is what I've missed in my test.

2. For executable file name changed, check all documents, including user's guide, readme, online-help, usage prompted in command line, etc.

I missed to check the usage help. It used the old name of the program.

3. Test special characters according to the file storage format.

For example, if a value is to be written to an .ini file with the following format:

#comment

[section]

param = value

Then test special characters like #, [, = in the input value. These cases are effective.

In my test, when I input "a=b" as the value, the program returned "param = a", which ignored the part after "=" in the value.

4. Execute with one single argument a time.

If a program can be run by multiple arguments, there must be cases that test each argument (standalone) at a time.

For example, if program ABC has 3 arguments a1, a2, & a3. Then MUST test "ABC a1", "ABC a2", "ABC a3" respectively.

Check out the lesson I learned: I only tested "ABC a1 a3" and "ABC a2 a3", and found both cases passed, then I assumed all 3 arguments were working. But finally in the last moment I found actually "ABC a1" and "ABC a2" failed. Only a3 was working. This bug should be found much earlier if test each argument alone first.

Of course, cases combination of arguments are required too.

2007-Oct-28 - Path / Directory test checklist

I summarize the checkpoints when we test file path:

(A) Normal cases

1. The path is absolute path
2. Relative directory

(B) Force Error

1. The Directory is read only
2. The disk space is not enough
3. The path contains wildcard char

(C) Internationlization

1. Directory with special characters
2. The path contains other languages
3. The path contains DBCS name
4. The path contains DBCS and SBCS name

(D) Platform compatibility

1. The path is Unix path
2. The path is double slash--C:\\test\\log
3. The path is single and double mixing slash--D:\\test\log\\abc
4. The path contains Windows and Unix mixing slash
5. The path is Unix, Windows, single and double slash mixing--D:\aa\\bb/c//dd
6. The path is DOS 8.3 format

(E) Other considerations

1. The path is UNC path
2. The path is networking mapped driver 
3. The path is very very long
4. The path is hidden.