software qa

Dec 24 2008   10:04AM GMT

Software Quality – Overlooked or Underestimated – both are dangerous!

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, QA, software quality, SQA, Quality Assurance, SDLC, software qa, Project Lifecycle, ChangeManagement, Project Development, QC, Development Manager

The goal of any software organization is to develop software applications in-house, or co-develop with an external agency, that meet and exceed internationally accepted quality standards. Every one knows it, that the key role in this is of QA department. With this intention, a dedicated QA department is structured in the organization, for the purpose. But most of the time, the move towards the objective mentioned above is limited or missing at all. Although the development managers too agree that in the software development business software quality is the key to their success.

In view of the above, the development managers need to revisit this area which mostly has not received all the necessary attention it deserves and which is something so crucial that the organization can ill afford to overlook.

Mostly, even if QA is in existence in the organization, it is used to test poorly designed and developed software. The reasons for this are well known, and the major one is that the QC is misconstrued to be a mere testing activity rather than looking at QC from a more holistic perspective. To this extent, the QA/QC department needs to be invited and involved at all stages of the software development lifecycle (SDLC).

To fulfill organization’s expectations and business goal in this regard, the development managers need to have a fresh discussion with QC/QA head to prepare a charter on how they plan to achieve it.

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 3 2008   10:11AM GMT

20 essential points for a tester

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

1.Focus on Quality Policy, Strategy, Test Plan, Test Cases.
2.Maintain heartfelt sympathies with developers who are developing Bugs (and their impact!).
3.Raise your anxiety higher for any software coming to you for testing.
4.Your first and foremost priority is to prevent the damage a bug spreads across the product.
5.Investigate the damage (impact of bug, through test cases).
6.Ensure safety of software by ensuring that you are able to catch all bugs.
7.Keep visiting developer’s den during testing to highlight the severe bugs found so far.
8.Work like craftsmen with high precision to attain micron-order accuracy in testing.
9.Be absorbed in your work and not even notice anything else happening around.
10.Be proud of your testing skills.
11.Have uncompromising approach towards ensuring bug free software.
12.Don’t worry about the rising count of bugs in the software (that ensures your job more secured).
 Trackback URL

Oct 30 2008   10:10AM GMT

Various Stages of a Bug

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Bug, software testing tips, softwaretesting, STLC, tester, Bug Management

A bug right from its insertion into the software till its removal crosses through different stages. These different stages of a bug formulate bug lifecycle. Each stage has an action and meaning connected to it. Various stages of a bug are:

Unconceived: A bug that has to come into a future software, not even knowing who is going to write it, and in which software.

Unborn: A bug not yet taken its shape, still lying in the mind of a developer.

Unconcealed: A bug residing in software but unrecognized by a tester.

Open: Any misbehavior in the software identified and recognized by tester is recorded with “Open” status.

False: Not actually a bug but marked as bug.

Disguised: A bug existing but identified with a different behavior.

Accepted: The bug accepted (as bug by project manager and its development team for a fix.

One time: A bug encountered by testers, but not encountered/simulated again. Such bugs are required to be fixed unless encountered again.

Not Accepted: Project Manager or development team may refuse to accept a bug in case it is not critical and seeking too much time to fix it, it is meeting customer requirements, tester has not understood the business requirement well and identified a wrong bug, or in case the same bug has already been reported.

Not to be fixed: The reasons would be same as mentioned in “Not Accepted”.

Pending: A bug accepted by the developer but may not be fixed immediately. It could be due to non severity, other priority or any other reason.

On Hold: Some bugs need to be discussed with customer, or management. Or the reasons may be as mentioned above in “Pending”.

Fixed: As soon as a bug is fixed by the developer, it is assigned as status as “Fixed”. A programmer must always doubly ensure before marking a bug as fixed.

Closed: The bugs marked as fixed once verified by tester and are found fixed are marked with the status “Closed”. Tester must doubly ensure before marking any bug as closed. Tester must also ensure that the bug fixed has not generated any other bugs.

Re-Open: A fixed bug found not fixed by the tester is to be marked as “Re-open”, which goes back to the developer for fixing.

Oct 27 2008   10:15AM GMT

Bug Control Management - a void promise! A flawed process! Or a process insanity!

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, Quality Assurance, SDLC, software qa, Bug, developer, Project Lifecycle, software testing cycle, software testing tips, softwaretesting, STLC, tester, Bug Management, Bug Control Management

There are three ways of functioning for any software organizations. First ways is to develop software and deliver it into the market. The survival for these sorts of organizations is too difficult and short. Second category of organization has a well placed “Quality” department in place. The quality department is responsible for ensuring a bug free product going out to the customer. The third category of organizations have a well identified and well structured team in place to ensure that every next production of software is going to have far less bugs as compared to the earlier produce. Most software organizations fall in category number two. Very few fall in category one, as organizations falling in this category will either not be able to survive for long, or will live on a very little customer base and profit. This is the third category that we are talking about – that falls in the bracket of “Bug Control Management”.

This organization lying in the third category will be continuously working towards improvising the processes of product development, ensuring lesser and lesser bugs in each of the next release of the product or new product. The progress of this team will purely be objective subscripting the improvement in every next product release. It does not mean that quality department will have no role now. Rather quality department will have a new meaning and more valuable role to perform.

But point to ponder here is – is it just a void promise, a flawed process or process insanity. Or is it just the darker aspect, brighter aspect is being felt by the organizations who have or are in the process of adopting BCM.

Oct 24 2008   10:15AM GMT

Bug Control Management vs Bug Management

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, Software testers, SDLC, software qa, Bug, developer, Project Lifecycle, software testing cycle, software testing tips, softwaretesting, STLC, tester, Bug Management, Bug Control Management

Bug Management and Bug Control Management are two separate aspects in software development. Bug Control Management seeks a higher maturity level in terms of organization, developers, project managers and all others involved. On the other hand, Bug Management starts in organizations with low maturity level. Organizations that attain the Bug Management level and keep it for years, stop maturing and keep a particular level of maturity sustained within them. There are organizations that move (over a period of time) from Bug Management to Bug Control Management. These organizations keep improvising and seeking improvements in their processes and procedures.
Usually a software organization life starts with software development. Gradually with the increase of business, increase of experience of developers, and increase in customer expectations an increased level of reliability in the software from all directions is expected. To cope up with this pressure, the organization creates a department called as Quality Assurance. This department takes care of testing of software, finding out bugs and getting it verified after the bugs are fixed by the development team.
Bug Control Management is a management initiative to involve all concerned to form a steering committee. The responsibility of this committee is to ensure that lesser and lesser bugs are generated in the software while development.

Oct 22 2008   10:11AM GMT

BLC or Bug Lifecycle

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Bug, developer, software testing cycle, software testing tips, STLC, tester, Bug Management

In simple terms BLC or Bug lifecycle can be defined as the different stages of bug. BLC or Bug lifecycle will consist of all these stages starting from the birth of a bug till its removal from the application. The various stages of bug lifecycle or BLC can be listed as below:

1. Bug induction or generation in the software
2. Bug identification
3. Bug behavior study
4. Impact study
5. Bug classification
6. Bug admittance
7. Bug removal assignment
8. Bug removal
9. Verification

The birth of bugs is unintentional, uncontrolled and hidden. A bug is prone to take birth while a code is being written. A bug is not a bug until it is identified or recognized.
BLC or Bug Life Cycle starts with an unintentional software bug or unwanted behavior and ends when the assigned developer fixing the bug.

Oct 8 2008   10:35AM GMT

Bug Management - Major Concerns being felt across the Globe

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Bug, Project Lifecycle, software testing cycle, software testing projects, softwaretesting, STLC, tester, project manager, testing environment, Bug Management

Senior Management including CIOs, QA Heads, CEOs, Development Heads, Project Heads, Customers, Vendors and/or sub-contractors related to software Organizations across the globe has repeatedly displayed their concern over the Bugs Management Process from time to time.

These concerns could be grouped as below:

1. The results of the Testing process are regularly inconsistent: This means that if same code is being tested by different group of testers under different leads, the results will vary always. Also the same team performing testing on different products will result in different performances.

2. The test results do not lead to more effective coding: The coding is always prone to create bugs (programmers are always as overconfident as ever).

3. The identification and quantification of a Bug is highly dubious: All the efforts by testing team in identifying and categorizing a bug is not always able to meet the seriousness it is meant for. Moreover sometimes a bug becomes an issue of debate over its category (critical/ severe/ desirable etc.).

4. Quality managers and testers often appear to have a limited knowledge of the code and business concepts and related issues.

5. Excessive focus and reliance on quantitative bug analysis is dangerous.

6. Bugs with a low probability occur more often than would be expected.

7. Bug management leads directly to bug avoidance.

8. Bug prioritization by Test managers is usually a simple ranking showing little or no understanding of the business process or customer requirements.

Most of the time the goal of testing is to diagnose the cause of bugs and produce better solutions. Instead the focus should be more on avoidance of bug generation at the code level so that least changes happen in the code once generated.