November, 2008

Nov 28 2008   9:55AM GMT

How to Create, Build and Maintain Harmony between tester and developer

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software design, Software testers, SDLC, software qa, software deployment, developer, softwaretesting, STLC, tester, software requirement

‘Create’ means the first time effort to generate a harmony between a tester and a developer working on the same project. ‘Build’ is the next stage after create to harmonize the professional relationship between a tester and developer. This step will bring the strength in the relationship. ‘Maintain’ is not only the sustenance of this healthy relationship which can be termed as ‘sweet’ harmony, but also calls for an effort from both ends to ‘keep on improving’ this bonding. To create, build and maintain an everlasting harmony between the testers and developers, here are some tips:
1. Share: Sharing is a two way process. Both the sides need to share equally, transparently and openly. The development team needs to share the customer requirements, business rules, relevant documents, design plan, coding, system built. On the other hand the tester needs to share his observations on all these, and the results of his testing. Share problems, thoughts and success together.
2. Raise an Alarm: Tester and developer require raising an alarm in case of any shortfall in above sharing required from both ends. Developer also needs to raise an alarm in case of inadequate testing or if testing is getting delayed due to any reason.
3. Act Jointly: Tester should sit with the developers while they are on job i.e. designing system, and similarly developer whose product is being tested preferably should sit with the tester while he is testing the product. This support will not only strengthen the process and product but will make it more secured.
4. Avoid Protectionism: On the work front, be it of a developer or a tester, it is important to prevent the spread of protectionism and to promote transparency or openness across the organization. If this is not handled properly, it may lead to depression and incoherence across.
5. Accept Framework: Accept each other’s work framework and respect it by heart.
6. Resolve crisis: In case of any crisis on any front leading to adverse effect on the project, take all necessary measures jointly, timely in a coordinated manner. Be more than willing to act in this regard.
7. Tester is a bridge: Tester is a bridge between developer and customer for the purpose of smooth and defect free delivery of product to the customer.
8. Be a great contributor: To achieve great success, be a great contributor in your respective fronts.
9. Encourage: Encourage each other.
10. Remember: Always remember that you have joined hands to achieve a common goal. A good harmony always brings in the ‘success’

Nov 26 2008   10:11AM GMT

New Release for testing – a tester’s paradigm

Posted by: Jaideep
software quality assurance, software testing, software, software quality, Quality Assurance, Software testers, software implementation, software qa, Bug, software testing tips, softwaretesting, tester, software requirement, software release

A new software release for testing could be a new product or major changes in the existing software. In either case the bugs report should have a new version number for control purposes. Although in case of a new release of existing software, the existing bugs can be referred to but that does not mean to check only for those bugs.

Anyhow before the tester starts testing of this new release (or for that sake of any new release!), (s)he has to make sure of three certain activities:
1. Clinical review of the testing requirements
2. Known bugs (in case it is a chain release) fixed
3. Scope – customer requirements, software requirement and business rules

And above all now tester’s task is to ensure that the software (re)built is completely aligned to the above three.

Nov 24 2008   10:14AM GMT

Challenges of Development/Testing and Open Source Test (OST) Tools

Posted by: Jaideep
software quality assurance, software testing, SOA, software quality, functional testing, Quality Assurance, performance testing, Software testers, load testing, RIA, software qa, AJAX, .OST files, Software testing methodologies, Bug Control Management, Open Source Testing Tools, Traditional Testing Tools, Web2.0, Selenium, HTMLUnit, TestGen4Web, PushToTest, volume testing, testingtool, testing tools

In today’s scenario when the schedules are tight, budgets are low and different technologies being used, software developers and testers are having great challenges of building/testing/releasing bug-free software by meeting all criterions. The question arises here is – how to cover all the development/testing requirements that to in such a short span of time with high rate of accuracy in development and testing. In such a scenario, the best option would be to use Open Source Test (OST) tools. And why not, when Open Source Test (OST) tools provide most economical solution and on top of it they are more flexible as compared to labeled vendor test tools (or traditional testing tools). So many big corporate organizations these days are using Open Source Test (OST) tools such as Ford, AMD and many more.

Many of the open-source testing tools support most of the technologies being used in development these days. Be it AJAX development or rich internet application (RIA) i.e. Web 2.0 on service oriented architecture (SOA), or any other web/server based application.

Some of the Open Source Test (OST) tools are – PushToTest, HTMLUnit, TestGen4Web, Selenium etc. that take care of functional testing, performance testing, load testing and volume testing. If you see all these testing are not possible to conduct manually and using a traditional testing tool would be never be a cost effective solution.

Nov 21 2008   10:55AM GMT

SDLC-VII: Deployment operations, maintenance and disposal

Posted by: Jaideep
software, SDLC, software deployment, software maintenance, software disposal

Once the software has been accepted by customer (user acceptance or software acceptance), on customers approval the software goes to customer site for implementation. A key user’s team from customer end is dedicated to this phase for the complete tenure. From vendor side also a team of technical and functional leads goes to customer site for implementation. The two teams jointly working as a single team start the implementation process by installing server, client software (by vendor technical team), training to respective module key users, test server setup, test run, and then live run.

By now the users should be quite comfortable with the software and also should be familiar with the functionality of the software. This is the period of deployment phase when user team is getting matured in running the software independently.

The vendor team should, even if it is there at customer site, behave virtually as if they are not there and should act only in case of a crisis. This virtual absence or inactive phase of vendor team will increase user’s confidence tremendously.

After implementation, for a period, stipulated and agreed upon mutually, there is a maintenance phase, during which a full remote support is provided by vendor team to the end users sitting at customer end. At times, if not possible remotely, some technical or functional person has to go to customer site during maintenance period.

Nov 19 2008   10:10AM GMT

SDLC-VI: Software acceptance

Posted by: Jaideep
software, SDLC, software acceptance

Software Acceptance or User Acceptance is an exercise that happens once the software has been cleared by QC. So far software has been tested internally only (by developers and testers). But customer also would like to test it and accept it prior to finally start using it. The phase is also important in case if any user requirement has been skipped, misunderstood or wrongly built in the software. Clearance by development team and testing team does not ensure that the product is meeting all requirements specified by the customer correctly and appropriately.

User would like to go through each functionality, process and rule with real data to ensure that the software is behaving as per the needs specified. Users during acceptance testing is supposed to run through each screen built and by trying data of both types – right and wrong to ensure proper handling of exceptions in the software.

Once the key users find software functioning fine, customer (management) accepts the software and then it is finally deployed or implemented.

User acceptance can take place at either of the locations – customer or vendor.

Nov 17 2008   10:15AM GMT

SDLC-V: Software testing

Posted by: Jaideep
software testing, software, SDLC, softwaretesting

Software Testing is the process to ensure a bug-free, fully functional software meeting all customer requirements. Testing starts right from the development stage. The developer himself is responsible for unit testing, smoke testing and code testing while he is building the code. Once different units, built by different developers, take the shape of a functional product, a need arises to test the product as a whole, each of its unit, each module and sub-module. This part is handled by a separate team known as QC, QA pr Testing Team.

Software Testing is very important to ensure:

1. It is meeting all customer requirements
2. All business processes have been built appropriately
3. All business rules are working fine
4. Functionally the product is ok
5. Each unit, sub-module, module and finally the product as a whole is meeting all software requirements
6. Exceptions are handled appropriately
7. User manual and software match
8. Software requirements, User manual and software match

Nov 14 2008   10:30AM GMT

SDLC-IV: Software implementation/coding

Posted by: Jaideep
software, software implementation, SDLC, software coding

Based on software requirements, business process, business rules, software design and customer specifications, the software coding begins. Project manager distributes the coding among the development team members with clear time frame instructions. Coding will begin in two manners – phased or sequential and parallel.

Phased or sequential coding is one in which the next coding part is not possible unless the first part is complete.
Parallel coding is coding that can be started simultaneously for different independent units between which the dependency is not too high.

Software Coding is the process of conversion of software design (concept) into reality.

Nov 12 2008   10:10AM GMT

SDLC-III: Software design

Posted by: Jaideep
software, software design, SDLC

Software design is the stage that comes next after freezing software requirements. The requirement specifications are given to the team of developers headed usually by a project manager. The project manager or the technical lead decides on the software architecture, OS, front end, back end, database etc. System design or ERD (entity relationship diagram) is prepared once the initial database design is clear with the table structures to be built in the database.

Software design is nothing but the conceptual design of the database, tables and table structures, relationship of various fields of tables with one another. Once conceptualized, it is discussed among the team, make any changes if required and then freeze it. Once the concept is finalized, the database is designed by creating tables and building relationships. The next phase that comes after is the coding.

Nov 10 2008   10:12AM GMT

SDLC-II - Applying security concepts to software design

Posted by: Jaideep
Security, software design, SDLC, security concepts

Security concepts will vary from software to software except few generic requirements that will remain standard for most of the softwares. The major varying requirements will be dependant on following factors:

1. Software requirements - Based on the requirements specified by the customer and the design this can further be divided into two sub-categories as below:

a. Customer specific: As specified by the customer and suggested by the vendor representative. The vendor in this case may be in-house development team or an external agency. The representative can be the IT Head, software project manager or any senior position in case of internal team, or a dedicated project manager or project head in case of the external agency.
b. System specific: The other major factor deciding on security concepts to be built in the software will be system design”. What architecture is chosen, what technology, what database, what front end etc.

2. Risk Factor – The gravity of risk involved and what level of security is required will decide on the security features to be built in the software
3. End User – What level or type of user is going to use the software
4. Money Matters – If there are any money related transactions in the software will require a different set of security concepts.
5. Statutory requirements – The outward or inward connection with other legal/non-legal agencies will formulate the specific security specifications. Also will depend on any statutory requirements to be met by the software.

Nov 7 2008   10:08AM GMT

SDLC-I: Software requirements

Posted by: Jaideep
software, SDLC, software requirement

Software requirements are the requirements that are given to the developer based on which they build new software. Software requirements could be functional or technical in nature. Broadly software requirements can be divided in two parts as – business process and business rules. Software requirements lifecycle can be defined in following steps:
1. Initial discussions – in this phase the top officials of the two parties (customer and vendor) discuss broadly the business requirements that are required to be built in the software.
2. Detailed discussions – this phase comprises of a team from vendor side that goes to meet the respective process owners of customer to understand the details of each process and the rules to build in.
3. Documentation – the requirements (process and rules) in the above process need to be documented in a clear manner because this is going to be the basis of software.
4. Forms and Reports – any forms and reports that are in business practice and have to be built in the software will have to be collected.
5. Sign Off – Never forget to get the complete document signed off by customer key users and top management