Home Index Links About Me Contact RSS
     
 
  Categories  
 
Java
Mobile Programming
SQL, PL/SQL
HTML, XML, JS and CSS
Android & iOS
Hi-Tech
Off-Topic
 
     
  Popular Entries  
 
Retrieving data...
 
     
  Recent Entries  
 
Retrieving data...
 
     
  Archive  
 
Retrieving data...
 
     
  Blogroll  
 
Bilal Hatipoglu's Blog
Hakkı Oktay’s Blog
Joe Stagner's Blog
Steven Feuerstein’s Blog
 
     
  Statistics  
 
Total Entries :
Retrieving
Total Entry Views :
Retrieving
Total Comments :
Retrieving
Total Entry Shares :
Retrieving
Unique Visitors :
Retrieving
Total Visitors :
Retrieving
 
     
 
  Building the bricks of software quality within a process  
 
Category : Off-Topic Views : 1147 Shares : 0
|
Date : 10.5.2010 20:02:48 Comments : 0 Rate!

In TestIstanbul Conference'10 one of the sessions that I enjoy a lot was about "Software Quality Assurance Process" integrated into Software Development Lifecycle (SDLC). It was conducted by Mesut Aksahin and Levent Arabul. As the main theme of their speech, they talked about a process that has some quality check gateways in order to handle project risks as soon as possible. Moreover, as most of the narrators, they pointed to the trade-off between software quality and time-to-market goals. This is a serious problem and have to be managed by quality assurance people with using test automation techniques and new test methodologies. In this article, I want to share information not only based on their session but also putting something from myself on it.

In that session, they presented the abovementioned process as follows;



According to this model, before the project goes live, it should pass through some quality checkpoints. For example, first of them is Analysis Document Review Workshops. In such workshops, project team criticises the analysis document due to ongoing system logic and to logic that the project should carry. When passing this step, it is expected from project team to have a mature analysis document. One more advantage of such workshop is to take the whole project team (from developer to operation people) into the project and make them know about project at the beginning. This approach helps people to find out potential bugs as soon as posssible.

Within this process, beside of code development and bug fixing, developers should do two more things; "unit test" and "pre-integration test". First of them is to prove that the code is working at its most basic level. The second one is to prove that the newly developed code can be deployed onto the ongoing system without any deployment issues by end-to-end testing the code.

After these basic controls, test engineers come on the scene. They do their functionalty controls with following steps: "Smoke test", "Functional Test", "Regression Test", "System Integration Test". In order to prevent ambiguity, short definitions of them are as follows:
Smoke Test: The initial step of the testing that ascertains the code is stable and is candidate for further tests. For example; smoke test of a newly developed procedure can be done by calling it with its parameters and seeing the result without any run-time errors. Within smoke test it is not expected to prove the correctess of returning values regarding to given input parameters.
Functional Test: Test type which is one step above the smoke test. In functional test, the developed code is examined whether it satisfies customer needs or not.
Regression Test: Within this test, the system in which the newly developed code deployed is working properly as it was before deployment.
System Integration Test: This test is for proving related systems are working and talking with each other properly. It is very critical when the project in hand contains multi-channel affect. This is another quality gate against new code and end-to-end tests should be run in order to prove this.

After ascertaining the code is as it is working properly, quality assurance people have to check whether the new system is working on predefined performance KPIs. To achieve this, load and performance test should be run with proper amount of data and load.

The final quality gateway is customer (or user) acceptance test. This should also be done because the final code has to be approved by the customer whether it satisfies his needs or not. (Please refer to my "A Game for Three Player" article referencing James Windle's speech)

Ultimately, when the code successes UAT tests, it can be deployed onto production environment. For the sake of more quality, new deployment in production environment should be observed by operation people to ensure that the system is going well in production and with production transactions.

Post a Comment Post a
Comment
  Share with a Friend Share with
a Friend
 
     
  COMMENTS  
     
 
There aren't any comments made to this entry, but you can be the first one ;)