Chuan Chuan Law

DevOps | Software Automation | Continuous Integration

Category: General (Page 2 of 3)

What Does A QA Do?

September 9, 2013 / / 0 Comments
I held a learning session with my team a couple of weeks ago about this topic “What Does A QA Do?” The reason is because I think as we are so much driven into the daily tasks and responsibilities to deliver projects and hitting deadlines, sometimes its good to take a pause and rethink, “What are you actually supposed to be doing?”
Who are we?
 
There are many definitions of the role. QA, tester, test analyst, test engineer. Regardless of what our official title is, I think we are simply part of the development team that help the team to deliver a quality and successful product.
What do we do?
 
Most would say we find bugs and raise them. Correct, but not just that. We link business requirements with technical design, into a quality end user product.
How do we do our job?
 
There are many technical terms for this, manual, exploratory, automation, regression, performance, security, etc. Firstly, we need to have the knowledge of a product manager to know what product are we building. Secondly, we need to have the knowledge of a business analyst to understand the detailed business rules behind each piece of functionality built. Thirdly, we need to have the knowledge of a developer to understand the system design,  and technical solution such as what does the code do, the data flow into the database, etc. Lastly, we need to be able to use the product as an experienced end user.
What type of bugs we find?
Most would think that bugs are software bugs, careless mistakes by the developers. This is only a minor part of it. Bugs can be:

 

  • Product bug – building the wrong product from the very beginning, wrong idea
  • Requirement bug – caused by lack of understanding of the business rules and outside the square thinking
  • Software bug – caused by wrong implementation
  • Environment bug – caused by the way the software interacts with an operating system, system configuration, database version, etc
  • Deployment bug – caused by sequence of deploying (e.g.: running a script prior update of code might break a system), code merge mistake, database backward compatibility issues
  • Performance bug – all the above bugs are eliminated, but we forgot to take into account that the system might break down under peak usage
  • Security bug – all the above bugs are eliminated, but we forgot that there are back doors or windows opened that allow intruders in to break the system and do nasty stuff!
Conclusion
I am not trying to over complicate things. Many would think QA only test. Yes, but a good QA does not only test. A good QA should have the following skill sets:
  • Good understanding of business knowledge
  • Able to think outside the square
  • Good communication skill with technical and non-technical stakeholders
  • Good team player
  • Good technical skills

 

 
 

Principles Of Regression Test

August 2, 2013 / / 0 Comments
I guess I have posted a lot of technical stuff in my blog. However, I would like to go into a more theoritical side of things about software testing today – how to write a regression test.
So, what is regression test? Everyone knows that it is a set of test to make sure that existing functionality still works after new functionalities are added.
But how to write a good regression test? Most would think that the more tests you add into a regression test suite the better it is. This is a wrong view about regression test.
There are rules to follow in order to write an effective and efficient regression test suite. These rules are:

 

  • Test all the core functions of the system (not the little help screen)
  • Test the happy path and user would follow (not edge cases)
  • Partition it logically based on system or core modules so that it is easily readable and accessible
  • Partition a set of tests that will be run before every release (very important core modules) and others that will only be run when necessary (changes occur)
  • Keep it as simple and short as possible
  • Avoid repetitive steps
However, please bear in mind that I am not trying to say we do not want to test more in regression test. I simply mean that most edge cases and low level tests should be in the unit test level instead of functional regression test.

Database Migration Test Script

March 4, 2013 / / 0 Comments

To assist the testing in database migration or database changes, I have built a script that does the following:

  1. Pass in the connection of the 2 databases that you want to compare
  2. For each database, list out all the tables in alphabetical order
  3. For each table, print out the number of columns and the number of rows
  4. Print out the tables that exist in Database A but not not Database B and vice versa
  5. For tables that exist in both databases, compare the number of columns, number of rows, and database schema (e.g.: varchar or nvarchar)
  6. If database schema is different, print out the schema in both databases

Software Testing New Year Resolution 2013

January 2, 2013 / / 0 Comments

 

  • Continue testing
  • Testing beyond testing (looking at business requirements, technical details, process, environment, etc as a whole)
  • Continue to read blogs/web about latest trend, tools, and technologies in software testing
  • Continue to identify tests that can be automated
  • Continue to explore and experiment the tools and technologies for test automation
  • Be creative and innovative in building test automation
  • Continue to write about what you have learnt in your blog
  • Go beyond a tester’s role (help identify cause of bugs and fix it if you can)
  • Enjoy what you do 🙂

Automating Email Testing For .Net – netDumsbter

September 19, 2011 / / 0 Comments

Email testing in Ruby On Rails application is very easy because of the Action Mailer framework.

However, .NET does not have such similar framework. After doing a series of research, I finally found something that could help a little – netDumsbter.

netDumsbter merely is a fake .NET SMTP server derived from Dumsbter which is popular for Java based applications.

We will use System.Net.Mail to as the SMTP client to send emails.

The example below is how netDumsbter is used:


#Initialises a new SMTP server
SimpleSmtpServer _Server;

#Starting the server at a random port each time, else it will throw errors
Random _Rnd = new Random();
_Server = SimpleSmtpServer.Start(_Rnd.Next(50000, 60000));

#Initialise a SMTP client by using the .Net “System.Net.Mail” library
SmtpClient client = new SmtpClient(“localhost”, _Server.Port);

#Creating a new email message and send it using the System.Net.Mail function
var mailMessage = new MailMessag(“cfm@mendible.com”, “kbm@mendible.com”, “test”, “test tes test”);
client.Send(mailMessage);

#Prints out how many email received via the fake SMTP server. In this example, we will get 1
Console.Write(_Server.ReceivedEmailCount);

#Stopping the server
_Server.Stop();

Conclusion

– .Net does not provide a good framework for email testing automation like Ruby

– The combination of netDumster and System.Net.Mail is good for unit testing purposes but not integration or functional testing

Goodbye & Thank You

August 5, 2011 / / 0 Comments

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 – http://au.linkedin.com/pub/chuan-chuan-law/21/540/b2b
or personal email – chuan.chuan247@gmail.com.

We shall meet again,

-THE CLAW-

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

Agile – A Major Transformation

June 14, 2011 / / 0 Comments

REA started adapting Agile SDLC in April 2009 by hiring ThoughtWorks as coaches.
It was a 360 degree transformation for the entire IT department.
How QA Involve in Agile SDLC
 
  • User story planning
QA is involved in the very early phase of development which is the user story planning phase. Here, testing of business requirements is done.
  • Estimation
QA is involved in the estimation of effort of each story card. The estimation has to be from development of story to the stage where it passed BAT
  • Acceptance test
Acceptance test is written using Cucumber based on requirements. The Cucumber features serve as the documentation for the system. Here, all the basic requirements and the edge cases are defined.
  • Development to QA hand over
Unit tests are inspected to ensure detailed cases like boundary values are covered
  • QA
Exploratory testing are performed as well as making sure that acceptance tests above passes. More tests are added if required.
  • Business Acceptance Testing
Walkthrough is performed with the product owners to ensure that the product meets their requirement
Benefits
 
  • QA involvement in the early development stage will ensure bugs are found as early as possible
  • Detailed acceptance test for each user story will ensure comprehensive tests are covered
  • More timely delivered project
  • Better quality
  • Involvement in writing automated tests and inspecting low level unit tests

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

June 9, 2011 / / 0 Comments
Date of event: June 2008
Bug:
Emails generated from buyers via the website were stored in the email server for 8 weeks and sent out at one go after that.
Cause:
 
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:

http://www.theage.com.au/news/biztech/agents-fume-over-realestatecomau-glitch/2008/06/24/1214073213392.html

Big bugs in REA history

June 7, 2011 / / 0 Comments

In my following blogs, I am going to step back to flick the unhappy times of realestate.com.au 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

June 7, 2011 / / 0 Comments
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.
Design
 
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.
Implementation
 
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.
Verification
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
 
Maintenance is normally quite expensive if new features are to be changed or added due to poor design.
Conclusion
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…..
« Older posts Newer posts »

© 2021 Chuan Chuan Law

Theme by Anders Noren — Up ↑