software testing tips

Dec 12 2008   10:10AM GMT

A Tester gets unlimited learning power when he becomes inhuman

Posted by: Jaideep
software testing, software, Software testers, developer, software testing tips, tester

As a human being we limit ourselves in how much we learn. The learning process is initiated based on certain facts like curiosity, need of the hour, intelligence, openness and related requirements. A tester being a human being carries all the limitations of bounding himself of these facts and thus sometimes may not be able to learn completely about a product that he is going to test as a new testing project. As a human being we tend to learn only the things that we are bound or forced to learn. That bounding or force may be internal (passion, habit, urge, eagerness) or external (work requirement, business demand, customer pressure, management requirement).

A tester for that sake should, at this juncture, think of him as an inhuman, away from all these sensitivities. Then he will not be limiting himself to any boundaries as mentioned above and will be able to learn or know maximum about the software, product or project he is going to start.

After all the accuracy and coverage of testing he carries on the software or product will depend on how much he has learnt or how much knowledge he has gained about this software or product beforehand.

The same thing applies to a developer also before starting development of new software or enhancing existing software in context to understanding the customer requirements and business needs.

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 5 2008   10:32AM GMT

Testing - A quick walkthrough!

Posted by: Jaideep
software testing, software testing tips, softwaretesting, tester, Bug Management, Bug Control Management

Here are some quick guidelines for a tester. As and when a new product (software) come to a tester for testing, (s)he should keep following things in mind to ensure the full justification to the purpose of testing. The purpose is to ensure a complete and correct testing of the product.

The guidelines are as below:
1. Assume yourself in customer’s shoe: Treat yourself as customer to run/use the product as they are going to use.
2. Walk with open eyes: When you walkthrough the product, keep your eyes open to observe the minutest variation/deviation in the behavior of each unit of the product.
3. Educate yourself before start walking: Before you start testing, ensure that you have thoroughly gone through the customer/business requirements documents.
4. Don’t compromise with the Docs: Ensure that the documents are complete in all aspects, as any ambiguity in documented business process/rule will have marred the purpose of testing and would lead to wrong results.
5. Don’t cross the red signal: If documents are incomplete or ambiguous, never start the testing.
6. Ensure all passengers are on board: The documents you are studying must be vetted by the customer and project manager before it reaches you.
7. Don’t sleep during flight: Keep your Pen and Paper or excel file ready as soon as you start testing. Keep noting each and every test case results.
8. Don’t take snacks at Food time: Place appropriate screen shots wherever required for your each test case results.
9. Ensure you have a right pilot in place: The project manager/ project team should be available to you while you are testing so as to ensure you all are travelling through the same path.
10. Appreciate the Air Hostess: Appreciate at places where a good job has been done by the developers by putting your remarks.
11. Mistakes are unintentional: Don’t blame the developers for the mistakes (bugs) in the product, purpose is not to punish or fire a developer.

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 6 2008   10:18AM GMT

Causes of Occurrence of a Bug in Software Testing

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

In my previous blog we tried to understand what can be termed as a Bug. Here we will (in continuation to that) try to find out the reasons of causes of generation or occurrence of a Bug.

A Bug shall occur in consequence to:

An effort to write a perfect code in terms of performance and/or function
An effort to embed business requirements in the software
A complex code structure in place of a simple code structure
Complex customer requirements
Repeated code change
Unclear understanding of business requirements
Unclear or incomplete customer specifications
Unclear or incomplete documentation
Multiple programmers working on the same set of coding over a period of time
Incompetent programmers working on a code
Improper coding tool selection

And sometimes a bug is passed as it is (uncaught or unhandled) in the final product released to the customer due to improper testing which can have very serious repercussions.

I will address to this issue in one of my next blogs on how to ensure that the customer gets a total bug free product.

Sep 29 2008   10:44AM GMT

Role of tester while verifying the closure of bugs

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing tips, softwaretesting, STLC, tester

When a product gets completed, it is released for testing to QC department along with the relevant documents. The QC department based on the scope of testing, availability of testers and the time at which the product is estimated to be released to customer, prepares its test plan. After studying the business and customer requirements, test cases and test scenarios are built by testers, based on which bugs or defects are reported. Once the bugs report (or defects report) is released to development team by the testing team, it is the development team that comes into the action. They based on the category, validity of a bug divide among themselves the bugs to be fixed and inform the testing team the estimated time required to close or address all the bugs/ defects. Once all the defects are fixed, the product goes back to testing team, for verification of closure of bugs.

The question arises here is that what is now the scope of testers for a re-released product. Does it suffice the purpose if testers just validate the closure of bugs? No, it is never going to be a fool-proofed product. What about the complete re-testing of the product for the two main purposes:

1. The bugs skipped in the earlier round of testing
2. The new bugs arisen during the fixing the earlier bugs reported.

This is very crucial phase and the testing in this phase needs to be more exhaustive and extensive than the earlier round of testing.