The Bug Life Cycle

 Just like a real life bug a software bug is also born and later bloom to attain many stages before dying i.e. getting closed. These stages so generic that each defect or bug can fall under its stages.

A bug/defect is always managed by a bug tracking system and there are lots of bug tracking systems available nowadays, this includes JIRA, BugZilla, TFS , TeamTrack, etc. the list is very large of such bug tracking systems. The choice of a bug tracking system totally depends on the business and the features required.

Though there are very generic stages of a bug life cycle still each bug tracking system follows its own cycle for a defect. All of those stages can later be mapped to generic bug life cycle (Refer to Diagram). A typical bug life cycle is explained here for a basic understanding.

New:

Life of a bug start with very discovery of a bug i.e. with the point of time when it is identified but in a bug tracking system life is considered to be started at a point when bug is first logged in the system and that state is commonly referred as New. That simply means that the bug i very much new and no work is done on it.

At this point no one can be sure of the person who is going to fix the defect but the defect remained in the system and can be discussed during team meetings.

Assigned:

Once the defect is assigned to a developer its state is changed to assigned, it simply means that a developer is working on the defect and the resolution can be provided soon. But a defect being in a stage does not always guarantee that a fix will be provided because at this point developer is going to study the defect which can lead to any result even to the rejection of defect.

From Assigned state defect can achieve three different stages which are explained here respectively:

Researching:

Many of the time developer needs to do some research to know more of the defect or to explore additional stuff in order to understand the behavior of defect and hence the state of defect can be set to researching till developer is researching. Once the research is completed defect is sent back to assigned state and developer can start working on providing the fix or can take other actions.

Defer:

The defect can be deferred if it is scheduled for a later release or some other reasons. Thus the state Deferred. The defect can only enter to state "New" from here similar to reopen from closed state. Please note that though this state is very much equivalent to closed but it is not exactly closing the defect because at deferred state we do not have a resolution for the defect but at closed state we have a resolution of defect.

Test:

At this state the defect is assigned to a test team member once the resolution of defect is provided by developer. A defect from assigned state can be sent to a tester with many of the resolutions that includes providing a fix or rejection of bug. Here, tester has to carry out required tests to verify the fix provided by developer or he can provide extra information to developer in case of rejection and send it back to assigned state.

In case of the fix, if all the testing goes well and tester does not find any issues then he can close the defect and so is the state closed. If at any point tester found any issue he can send the defect back to developer in assigned state with reason as "retest failed" and here developer again has to work on the issue and can come up with a resolution as described in Assigned state.

Closed:

If the testing for the defect proves that the defect is fixed than the defect's state can be changed to closed which means the defect is now fixed. This state can be achieved from deferred state as well e.g. if a defect was uncovered at a time and was sent to deferred state after few releases that issue becomes irrelevant and hence can directly be closed.

Once a defect is closed it doesn’t mean it cannot be observed again in the software. Though it is very rare but if same defect is observed again then the defect at state closed can be reopened and sent to New state.

These are very generic states a Bug/Defect can have and these can further be divided into other states as per the implementation of a bug tracking system.

The Principles Of Testing

Every profession has some building block or principles and likewise any other profession testing too have some principle on which it relies. These define very basic yet roots of software testing and should be kept in mind while testing.

Software testing has seven basic principles and each of them have its own meaning /purpose. We can go in detail with each of the principle to understand its meaning.

Principle 1 – Testing cannot prove there are no defects
"testing shows that there are defects but it cannot prove there are no defects"

The basis of this principle is the fact that it there are always some scenarios /combinations left which are either not possible to test or are less important. Testing can always reduce the possibility of finding a failure of software in production but it cannot guarantee that the software is defect free.

Let’s take an example of some mail server like GMail or yahoo mail, no matter how thoroughly it was tested there will always be probability that it will not work properly on some newly developed browser. But after testing it is guaranteed that mail server will work on most of the web browsers.


Principle 2 – Exhaustive testing is impossible
"Exhaustive testing is not possible except of trivial cases."

Testing everything i.e. each and every possible combination of inputs and the precondition is not possible because there are constraints such as time limit or the cost of testing and in some cases testing each combination is not even practical.

For example if a user ID on a login page accept numbers and characters with a total max length to 15 then it would not be practical to test each and every combination of characters that are accepted for the user ID. That will consume much of time and will cost too much even if done by some automated program.


Principle 3 – Early testing
"Testing should start as early as possible in software development life cycle"

Once the development is started there remain many defects which costs more to fix then to fix them in requirement phase only or in other words if it is the responsibility of software testing to ensure the quality then imparting the quality process late would obviously cost something. As the development progresses costs to fix a defect increases because the area affected by the defect can be increased and/or the complexity of code is increased.

If a product has a feature which can never be used or wrongly represented in requirements document and testing is not started early i.e. with requirement phase itself then it would obviously convert to a faulty design and a lot a rework might need at later stage but if the testing process is implemented in the very beginning of software life cycle then the faulty design can be identified and the amount of rework can be reduced very much.


Principle 4 – Defect clustering
"A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures"

Usually it is observed that most of the defects that are identified for a software are from certain modules only and the testing should be focused on those modules only after observing the defect density.


Principle 5 – Pesticide paradox
"If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects."

We can understand this principle by the example of an agriculture farm where a farmer is using facing problems with some pests. Now one of his friend suggested his a pesticide, the farmer started using it and found that it removed the pests very significantly. He was so impressed that he used the same pesticide next year as well and then next many years. After few years he observed that his crop has developed pests and his old best friend the pesticide has no effect on the pests. He was very surprised and was not able to figure out the reason for the problem. any guesses why this happen?

Answer is simple, pests have developed immunity for the pesticide over the time.

Same thing happen with the software also, if same test is applied to the software repeatedly then the test would no longer uncover any new defects. Hence, to overcome this "pesticide paradox" it is advisable to always try to update and enhance your test cases. New and different test cases should be added to the test suit so that new defects can be uncovered.


Principle 6 – Testing is context dependent
"Testing is done differently in different contexts"

Same things are done differently for different contexts in our real life as well, like saying hello to your parents will have different tine than saying hello to your friend.

Similarly in software field testing is also done differently for software with different purposes. Like for a e-commerce website testing money transaction related tests is very crucial while for a satellite software most important thing is to make sure that satellite is able to communicate with ground station successfully


Principle 7 – Absence-of-errors fallacy
"Finding and fixing defects does not help if the system built is unusable"

Sometimes this happen that a software is built and validated with QA but still that remains unusable because it is unstable and does not fulfill the user requirements. So, it remains duty of a QA tester to always think from a user perspective and provide a feedback as if real production user would have been using the software.

Software Testing- Constructive or Destructive

Often I heard a question about software testing. Is it a destructive process or a constructive one.

People generally messed up the answer and the person asking the question actually expect the answer as destructive and most of the person goes with that only.

The reason is simple software testing needs a mind-set of trying to break the application/software and thus needs to be a destructive process. But that is not completely true because when a new building is built then ground is cleared by destroying the old structure and that remains the part of construction. Similarly, software testing is done to prevent business facing losses from on-field exposure of defects. So, it can be said that software testing is a destructive process to achieve a purpose which is constructive.

On the other side, if we look at the process of conducting software testing then we will find it very well structured and defined but a destructive process can not be very well  defined. One can understand this by simply looking anything which was destructed. When something is destructed then it is very much expected that something of it remain rigid and intact. It is like destructing a building by a powerful explosion just to find of some of the wall standing even after the explosion.

But software testing is conducted in a way to exercise each and every part of software/application, it is very much similar to destructing a building systematically while ensuring that every brick of the building is moved.

Thus, software testing is a destructive process which is conducted in a very constructive way.

Cross domain access via windows authentication for SQL server

“Ohh.. eh… Why I cannot connect to this SQL server with windows authentication hosted on other domain. I tried everything but that is not working. :( :( ”

Ever caught in a situation like this?

Once I was also caught up in a problem similar to this one. I needed to access SQL server hosted on other domain and we had only one server from which we could access that and the number of people using the server was very high 5-6. So, it was not possible to login into machine simultaneously.

We then find a solution to launch SQL server client at our local desktops under that other domain. That invocation under separate domain is a bit tricky and works on “RUNAS” command.

All one have to do is follow below mentioned steps:

1.       Open command prompt

2.       Type following command RUNAS /user:<Domain name>\<Username> /netonly ssms

e.g. RUNAS /user:otherdomain\myuser /netonly ssms

3.       Provide username and domain in above command as shown in example

4.       Press enter

5.       Enter password when asked as displayed in below screen.

6.       Now your SQL server management studio will launch. Provide the database name hosted on other domain in the server name.

7.       Select authentication as windows authentication. It will display your local domain, ignore that.

8.       Click on connect

9.       On first attempt you might get timeout error but on second attempt you will be able to connect directly.

Load testing: JMeter part 2

Using JMeter for a Simple Test:

Let’s see how to run JMeter now. We will conduct a simple test to set up a test plan and stress test a Web application. Before proceeding with the test we need to have a test plan first which will help the JMeter to perform the testing in steps. There are several elements in a test plan like thread groups, listeners, assertions, sample generating controllers, logic controllers etc. Well, these elements will be described later. One point to remember here is that a test plan must have at least one thread group having all other JMeter elements which is the starting point of a test plan. All of the other threads created by the JMeter to simulate simultaneous users will be controlled by this thread group. Let’s go through the steps now. 

Load testing- JMeter Part 1

Load testing focuses on simulating and often exceeding your expected production load, throwing many concurrent requests at your site for an extended period of time. The key to load testing is realism. You need to know your application and your audience well, so that you can balance your load across your application in a way that closely mimics your actual or expected production traffic.  

Transaction log full error on MS-SQL Server

Working on SQL Server, ever seen this error message:

The transaction log for database 'mydatabase' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

When this error encountered you will not be able to do any updates to your database and will remain stuck. The point interesting here is that this troubleshooting information provided with this error message is of very less use.

Lets dig into this error to find the cause and solution for this problem.

Cause:

    This error suggest that the transaction log is full. We should understand this differently. The disk space on the drive where this database is hosted is full and SQL server is not able to write into transaction log. This normally happen when the transaction log file grew much larger.

There are many options to solve this problem.

1.      Quickest resolution for this is to clean-up some disk space by deleting few unnecessary files (if you are able to find anything). This is just a temporary solution and soon you might got hit with this error again if you have not configured any clean up task in SQL Server.

2.      The other way is to shirk the database by simply by right click menu. Remember always,

a.       You have to first take a backup of your transaction log for disaster recovery.

b.      You have to detach the database prior to shrinking else it will throw an error. This can also be done from right click menu 

3.      The third method is only recommended to use if you are not planning to recover your database (normal in development environments). The method is to set the database recovery model to simple. Can be done by following path in SQL Server.

           

            Right click on DB name from object explorer-> properties-> Options-> Recovery model->                    Choose “simple” from drop down. (See screenshot below)           

      Once the recovery model is set to simple you will be able to truncate existing transaction logs and  they will not grow in future.