DevOps | Software Automation | Continuous Integration

Tag: REA

Goodbye & Thank You

Today is my last day at REA. Let me post my goodbye email as this last post via REA’s laptop before returning it.

Will spend my last few hours here saying goodbye to everyone and looking forward to a fresh start at Page Up People on Monday! 🙂

Joining REA on the 12th of December 2005 as the sole junior tester, I have been through a lot with REA along the 5 years 7 months plus of journey.
From the launch of RCA1.0 to RCA2.0, launch of PFC to the closure of PFC, Blue Screen to ACCPAC, multiple manual regressions a day to Selenium automated tests,
Waterfall to Agile, Windows desktops to Mac laptops, etc.

REA has given me a lot of opportunities to learn and grow both professionally and personally.
I have also met a lot of great friends and colleagues which have made working at REA really comfortable and enjoyable.
Coming to work every morning is just like leaving home to another home.

However, it’s probably time to get out of the comfort zone to explore and try something new in life (a sign of having late 20s crisis??? lol).
Ok, this is my last joke here, again I would like to thank REA and everyone here, from the past to current, for making my time at REA so fruitful.

Goodbye (for now) and thanks again. 🙂

Feel free to keep in touch with me at LinkedIn –
or personal email –

We shall meet again,


p/s: Some classic quotes for me from some sweet people:

(1) Adam Hope – It’s probably good to move before you become part of REA’s furniture

(2) Manisha – There will be many kiwi fruits left in the kitchen

(3) Ado – Yeah! No one will fight for passion fruits with me

REA Big Bug 1 – Buyers’ emails not sent to agent

Date of event: June 2008
Emails generated from buyers via the website were stored in the email server for 8 weeks and sent out at one go after that.
REA’s operation team upgraded the email server which was not tested.
Why the cause could happen?
Operations team back then was independent from other technical teams, especially the QA team.
Server upgrades, etc done by the operations team were not visible to the other team or business.
What we learned by it?
Operations team should engage with developers and QA team. Work done Operations team are expected to be undergo the QA team.
As result of this, the QA team was expected to have the system administration side of skills set.
News reference:

Big bugs in REA history

In my following blogs, I am going to step back to flick the unhappy times of where big bugs were found in production with massive impact (eg: appearing on news), and most important of all, WHY did it happened, and WHAT we learned from it.

REA..with the traditional way and its flaw

Waterfall SDLC Model

The above model is how IT world works for many years, which have proven working for many organisations, including REA.
I am not going to talk about how it works but will talk about how it does not work instead. It is actually not the flaw of the Waterfall model, but the way REA adapting the model.
This is the phase that is normally being taken short cut or even skipped. This caused a lot of problems found later in the development phase that is expensive to fix.
The way the design was done was writing Technical Overviews. TO provides a good guideline on how to implement the system but this does not look at the entire system from a broader view or architectural level.
Without good design, design is normally based on TOs which are derived from functional requirements.
This way of implementation will be able to meet users requirements, however, does not mean that the system will be easily maintainable, portable, extendable, secure, etc.
Thus, budget and time normally overflow in this phase.
Due to project deadline and overflow from implementation, verification is normally the most painful phase.
In order to rush products into market, buggy features are taken out instead of being fixed properly, short cuts are being taken, etc. All these pretty obvious are not good practice in software development.
Maintenance is normally quite expensive if new features are to be changed or added due to poor design.
As a summary, the old way REA was working was quite painful to work in. Quality and quantity of products produced were also not much of a happy case…..

REA…the next journey

I was employee number 175 of REA. Back then QA department was initiated and ran by a one man show (Malcolm Webster).

Being the 1st test analyst of REA, I have travelled a long journey of ups and downs. I had to be responsible for all systems of REA, from backend to front end, to the ticketing and financial systems. Basically, I was put in a situation where I have to “do everything”.
In my following blogs, I am going to talk about how REA work in the Waterfall SDLC model.

© 2023 Chuan Chuan Law

Theme by Anders NorenUp ↑