Thursday, December 30, 2010

Testing World 2006

Hi All,

I have attened the Testing World 2006 conference today & the response was tremendus. The session on Testing Skills That No One Talk About by Michael Bolton was too good and put me in different thought process on the areas left out to explore.

He talks about

  1. General Systems thinking
  2. Critical Thinking
  3. Debating Skills

Testing World 2006 is the conference for building your expertise in testing projects execution & various products. It's two power-packed days of practical information you can take back to your job and put to work immediately.

These kind of conferences helps testers to know what's happening around and how can we benefit from the same.

Applying Static Analysis for Software Testing

In this post, I will be sharing my views on Static Analysis and how the same is useful for Software Testing. Using Static Analysis in Testing will also be called as Static Testing.

The generic definition for Static Testing is that

Testing of an Application at the specification or implementation level without execution of that Application.

Static Analysis helps a lot for better Code Quality and we can perform the following set activities against the source code.

  1. Capture Metrics
  2. Complexity of the System (eg. Cyclomatic Complexity)
  3. Compliance against Standards (eg. check for the Java Coding Guidelines)
  4. Exception Handling (Captures the code that contains Unhandled exceptions)
  5. Infinite Loops
  6. Copy Paste Dectors (Most of the developers used to reuse the code via a copy paste and introduce some issues in the process)
  7. Duplicate Code
  8. Dead Code

We should be able to restrict most of the above said issues at very early stage of SDLC by applying Static Testing techniques and make these part of the build process.

Finding Bugs in Java Programs with just one mouse click

Come across this cool video about Using Static Analysis For Software Defect Detection on Google Tech Talks. William Pugh talk about how can we use Static Analysis for defect detection and his tool FindBugs which is Static Analysis tool for Java Applications.

The tool is amazing and with just with one mouse click, we can uncover so many issues that we didn't even think of.

Get more info on FindBugs here

Link to the Video : Using Static Analysis For Software Defect Detection

Abstract of the Video:

Paugh talks about some of my experience in using and expanding static analysis tools for defect detection. The FindBugs tool developed at the University of Maryland is now being widely used, including inside Google.

he will give an overview of FindBugs, show some of the kinds of errors we routinely find in production code, discuss the methodology we use for enhancing and expanding FindBugs and some of the recent additions to it, discuss ways of incorporating FindBugs into your development process (such as being able to get a report of all the warnings introduced since the last release of your software), and talk about the future of static analysis, including things such as a new Java JSR to provide standard annotations for things such as @NonNull and @Tainted.

Is Counting a Bad Idea for Test Effort?

I was going through the post Why counting is a bad idea on Shrini's Blog on Software Testing. Shirni has listed a classic example on why counting is a bad idea for Testing.

Even though i like this post, I won't agree fully on the views expressed there. Probably we might need to improve our selves with the process of measuring.

Certain artifacts like test cases, requirements and bugs are not countable things and any attempt to count them can only lead to manipulations and ill-informed decisions.

Wait — Are there any things at all in testing that we can count without loss of effectiveness and usefulness of the information that a counted number might reveal?

Let me describe my stand clearly wrt to this Why counting is a bad idea.

I do agree that it's not posssible to count all the activities that we do in testing. But then that doesn't mean like all the Test related metrics are bad. May be, We can't generalize them since it leads to lot of subjective debate.

When it comes push the usefulness and effectiveness of the information by the metric, this is more of a improvement process. All these metrics are subjective to the respective projects / environments / organizations. Any attempt in making this as a genaral metric will lead to manipulations and ill-informed decisions.

  1. Bad Idea for whom ?
    Is this for Customers / Management / Developers / Testers / Others
  2. If Counting is a bad Idea, how do we measure the effort spent for the Project ? Do we need to go by the gut feelings of te people ? Will there be any data to justify our decisions ?

Most of the metrics used for Software Development for that matter are subjective. It varies based on the application, technology, domain, global support etc. It's tough to make them general like we do in other industries. So the same will be applicable for Testing too.

Some thing like below are very much subjective and won't be accepted in genaral.

Productivity

  1. No of Test cases prepared Per Person Per hour = 5
  2. No of Test cases executed per person per hour = 15

Look at the subjectivity in the above scenario.

  1. What is the structure of the Test Case ?
  2. How many user actions will be there in genaral per TestCase ?
  3. What is the Volume of Test Data associated with each TestCase ?
  4. What information available for these Test Cases (SRS, Design, UseCases etc) ?
  5. What kind of test cases are they writing ? Are they writing for Unit, Integration, System, Accepatance, Performance etc..
  6. What kind of Test Design Tech are they following (BVA, EP, DT, OA, CE etc)

There will be so many queries that will be come up here and it's tough to measure some one just based on the number in genaral. But then since it's subjective to the project (team), the respective stake holder should be able to take some decision based on that number.

But then, we can't make this number generic. Probably this might be useful to the similar projects to have some rough estimate.

At the end, i shouldbe able to give qualitaive (again this is subjective) to the stake holders. If some one expects 100% qualitaive info here, that's an ideal world to which we can't go as of now.

What does that mean ?

I should be able to give a number. My metrics should tell me the number of Test Cases, Issues etc wrt the requirement.

Otherwise we may not have clarity on what we are doing & what are we trying to deliver. Things will be going on the pure gutfeelings

Pradeep has come up with nice replies to my comments on the post.

@Pradeep,

Thanks for sharing your views.

Let me look at your requirement

" This field should take only alphabets and nothing else other than that "

In the first place, the requirement is not clear for me

  1. What kind of Application are we taking about ?
  2. What is the size of this field (Some thing like password. It should have a Min and Max length)
  3. When you say Alphabets, Do you mean to support all the alphabets in all the languages or just english or some thing else?
  4. ????

See Pradeep, my queries will go on like this and all these will help me in getting the clarity on the requirement. This is how i try to to understand the system.

This process helps me in knowing on what is the requirement, it's advantages, it's limitations and most possible scenarios where this can be used.

All the above will help me in capturing the required tests for the above requirement.

But this may not be generic on the whole but then it can be generic to the Organization or at least to the project people are working with.

See there should be some way to measure on what we are doing. This measure should help the stake holders to take a decision on the quality of the application under test.

I do agree on the fact that we need to improve ourselves in coming up with measures that have qualitative information for the stake holders.

@ Shrini, Thanks for coming up a post that has good debate.

That’s expected behavior and Not a Bug

I keep hering the following phrases from our Development Team here

  1. That's an expected behavior and Not a Bug
  2. That's by Design

Today, I have an interesting debate with our Product Manager on a Issue. He put is as "That's an Expected Behavior and Not a Bug"

I have been looking at root causes of these problems & why do run into this kind of debates always. The following limitations came

We could have avoided the same incase if

  1. Clarity on the Requirements across all the teams 
  2. Limitations of the Technology
  3. Usability Principles (UI Guidelines)

The above two arguments can be avoided if both teams have clarity on the above three.

Tester is not a Quality Police

The perception from most of the management is that the Testers are the quality police for the products / projects that they develop. This is true for most of the companies where there is no Quality Assurance group.

What do i mean by a Quality Police ?

  1. Is the requirements freeze done for the product
  2. Did we write all the specs like SRS, Design Docs, Uses Cases
  3. Are the developers writing Unit Tests ?
  4. Are the developers testing the builds before pass on the same to Test
  5. This list goes on…

There are testers who are trying to do the above and i call them as Quality Police .

Where does this attitude come from ?

The attitude of acting like a Quality Police for testers is injected by the management from the beginning of their careers. So they expects the same as they go along with their career and this attitude spoils the relationships between developers and testers.

Acting like Quality Police and trying to get things done is more of process which need to be followed by all the teams and let's not take that up. Let the management take care of the process management too.

What is Quality ?

Wikipedia describes quality assurance as follows

Quality Assurance is the activity of providing evidence needed to establish confidence among all concerned, that the quality-related activities are being performed effectively. All those planned or systematic actions necessary to provide adequate confidence that a product or service will satisfy given requirements for quality. Quality Assurance is a part and consistent pair of quality management proving fact-based external confidence to customers and other stakeholders that product meets needs, expectations, and other requirements. QA (quality assurance) assures the existence and effectiveness of procedures that attempt to make sure – in advance – that the expected levels of quality will be reached.

Read more on Quality Assurance from wikipedia

It's worth noting here that Good Quality doesn't come from less bugs in the product. I have seen people whose assumption is that if a product contains bugs it's of less quality and in case if it doesn't it's of more quality. I would say that we can't measure the quality of the products just with Bugs. I have never seen any product which doesn't have bugs in it.

Are the Testers responsible for the Product Quality ?

The Testers test the product and report bugs. Some of these bugs will get fixed for the release in case if they are import. You can't build quality into systems just by reporting bugs and helping developers to fix them.

Assuring the quality into Products under development is the responsibility of all the teams associated with Product Development

So What should be the Role of Tester then

The role of the Tester to test software, find bugs, report them so that they can be fixed. The Bug Reports should be clear, easy to reproduce, reduce the time to debug the same for developers and the report should motivate the developers to fix the issue asap.

Tester should focuses on the software product itself and gathers important information regarding what it does and doesn't do. The process of gathering should include all the teams associated with the product. Talks to management, sales, architects, development, support and gather their expectations over the release.

Don't you think that this is a big job all by itself and need lot of time. As i keep saying the Role of the Tester is to provide qualitative information on the product to the management for the better decisions. So the big challenge here is to provide accurate, comprehensive, and timely information about the product under development.

KLOC – What does it mean to Software Testing

Introduction to KLOC

Lines of Code (LOC) is one of the software metric that is used by most of the people for Software Measurement. Thousand lines of code is treated as KLOC. This metric helps us in knowing the size and complexity of the Software Application. Click here for more details on KLOC. This info is from wikipedia

What does it mean to Software Testing

We do test applications with the intention to see if the promised functionality works fine or not. Any deviation here will be considered as a Bug. So each of these bugs must be originated from some line of code in the product.

So it's understood that when the size of the code is more there is a chance for more number of bugs in the prodcut. Even most of the process to talk about some % of issues is fine or acceptable quality per KLOC(even though there is lot of subjectivity).

The Defect Density is arrived at Number of Bugs / KLOC per the product under test. The defect density is one of the metric used to measure the quality of the product. Most of the Quality Process does talk about this metric.

Concerns

The concern in this approach is that how these values are measured. The general bias with KLOC is that people try to see that only the excutable lines of code in the product.

Each every line in the product may not be code at all & we may not execute each and every one of them. So it's not taken care, then the issues related to documentation, images, installation etc might be misleading.

Since we are looking at KLOC as the size of the product it's better to include each and every entity that effects the same. Then it's helpful for both development and test teams.

Software Testing Magazines

Testing Magazines helps us to know the latest trends / happenings around the industry. These will list the methodologies, tools, techniques, expert talks and some of the best practices that are useful to the testing community.

Through this post, I would like to list the magazines that are useful. I have been following through the below list of magazines since a while and these does helped a lot.

Software Test and Performance from BZ Media

Brought to you by BZ Media LLC, Software Test & Performance helps readers improve the efficiency of their software QA and testing processes, as well as help them improve the performance of their in-house applications pre- and post-deployment.

Better Software from StickyMinds.

Better Software is the magazine for software professionals who care about quality. Each issue brings you relevant, timely information to help you build better software. Continuing to deliver in-depth articles on testing, tools, defect tracking, metrics, and management, it's the only commercial magazine exclusively dedicated to software professionals. Within the pages of each issue you'll find heavy hitting articles about solutions to common management problems, coverage on emerging technologies, and more. You'll benefit from expert analysis and real-world case studies in the areas of Testing & Analysis, Managing People & Teams, and Tools & Techniques.

Methods & Tools

This is a free magazine with PDF and text issues that provide practical knowledge and information on all topics of software development and software engineering: UML, Agile Methodologies (eXtreme Programming, Scrum, TDD, FDD,..), Software Testing, Software Configuration Management, Database Modeling, Java, .NET, RUP, Software Project Planning and Management, Test Automation, Programming, Software Analysis and Design, Quality Assurance, Software Process Assessment and Improvement, Software Development Tools, Risk Management, Refactoring, IT News, etc.

The Professional Tester

Professional Tester is the leading publication targeting professional testers of software worldwide. It is a 32-page, English-language quarterly magazine with a circulation of approximately 15,000 subscribers and is now in its sixth year of publication. Subscription is free to qualifying industry professionals. Professional Tester is completely vendor-independent and is currently the only European publication covering the rapidly growing software testing market.

The Tester from Specialist Group in Software Testing

WINNER of the BCS Best Specialist Groups Magazine award!. The Tester is the newsletter of the SIGIST. It is published a few weeks before each conference and contains advanced details of the conference as well as a booking form.

Role of a Tester – An interesting discussion with an upcoming tester.

Today i had an interesting discussion on the role of the testing with an upcoming tester Debasis from Chennai, in India.

Debasis: Hi venkat

Venkat: what's up debasis

Venkat: going great. Happy Testing and more posts on my blog these days.

Venkat: That's interesting. let me ask you some stuff on Testing

Venkat: what's the role of testing in SDLC

Debasis:The same as of parents in the upbringing of a child

Venkat: oh. That's interesting. But don't you see it's the role of the management more

Debasis: Okay b4 I cud answer, i want ur definition of SDLC

Venkat: The process used to develop software the phases involved init

Debasis: But to me the processes can be of many types and of different approaches. Assuming that I am following a generalised SDLC approach…

Venkat: go ahead.

Debasis: The role of testing is to ensure that the intended user gets a good quality product after the release

Venkat: hum. good quality product. great go on.

Debasis: But that in no way mean that the Product is Completely bug free after testing

Venkat: So what do you mean by a good quality product then. Are you acting as a quality police in order to get the good quality product out.

Debasis: what do you mean by quality police

Venkat:Look at this post to get some info on quality police

Debasis: oh no. I have not seen a quality police in my entire career. There may be ppl claiming to be quality police

Debasis: But my role is to point out important defects as quickly possible in a given SDLC phase

Venkat: that's great to hear and expecting the same. u r coming on the track now. This is the role of testing.

Debasis: Thanks…

Venkat: Catching up important defects in early stages helps a lot. This is how you can become the headlights of the project as James Bach used to say by giving the right information at the right time.

Debasis: Yes u r right

Debasis: And to try and get them fixed b4 a Product release

Venkat: hum wait a while let's discuss on fixing the issues part at a later stage.

Debasis: oh ok.

Venkat: How do you know that the bug that has been discovered is critical or not.

Debasis: Simple. If the defect is such that which may/can bother the stake holders of the product, them I assume that its important.

Venkat: Are you assuming ? Will there be any evidence for this bias.

Debasis: might be checking with the docs and stakeholder will resolve the conflict.

Venkat: That's good to know.

 

Venkat: let me come back to this. Are you trying and get the issues fixed b4 a Product release

Debasis: yes. It's my job to get all the issues fixed that are reported by me.

Venkat: Does your bug reports clear for the deveper to re-produce the same.

Debasis:Yes there are really good.

Venkat: Does your bug reports contain complete information on the bug. A story about the same and helps developers to reduce their debugging time for the issue.

Debasis: And I as far as reproducibility of an issue is concerned, I am thankfull to god to have been gifted with gr8 bug reporting skills :)

Debasis: Also sometimes I am assigned to try n reproduce some hard to reproduce issues posted by other testers

Venkat: that's great man. So what do you mean by trying to get the issues fixed.

Debasis: Convincing, motivating & helping the developers to get the issues fixed.

Venkat: oh is it. Why do you need to do it. Let me ask you some thing different. How many times did the developers tried you to convince, motivate and helped you to uncover more issues in their code. Think for a while on this.

Debasis: What ?

Debasis: Hmm.. May be u r rite. Will definitely think over it

Venkat: you have given the enough information on the issues so that they can be re-produced or to debug the same. And more over you have also given it's relevance wrt it's stake holders.

Debasis: But isn't my job to get my issues FIXED? If they r really imp.

Venkat: No way. That's the role of the management. If they are really imp, they will get it fixed. Why should u worry about the same and spoil the relationships with the developers.

Debasis: hmm, good point. will try to ponder about it

Venkat: most of the testers here in india see Testing as a support function to the development. So this has been there in their mindset.

Debasis: But I don't. I see Testing as an important part of SDLC which can't be substituted by anythingelse

Venkat: That's great to hear. If that's the case, i don't expect the statement, But isn't my job to get my issues FIXED?. how many times did ur dev team asked to report bugs on their code ?

Debasis: May be u r rite. Will definitely think over it

Venkat: The role of tester is to catch the imp bugs at the early stages and give complete info on the same as qucikly as possible. It should contain all the required info for that issue to reproduce.

Debasis: Sure, thanks. Any way, I enjoy chatting with you

Venkat: i want an upcoming testers like u to be very clear on the role of testing and the role of tester. Once this is clear, you can explore on the skills that are required for that role and improve the same. hope this helps

Debasis: Thanks again for sharing ur views on testing with me

 

Enjoy the reading and share your views

Taking on “Testing Triangles – A classic excercise”

Solving puzzles, sudokus & the analytical problems is one of my hobby. This set of puzzles always helps me with some brain food which mandatory to stay tuned in the current trends.

I was going through this Testing Triangles post from Elisabeth Hendrickson from Quality Tree Software. The triangle program is very much popular to the world of testers and many of the books and blogs have already covered the same.

Elisabeth posted this as a testing puzzle and asks the people to uncover the bugs in her program. The beauty of this Triangle program is that whole code is available for the tester since it's written using JavaScript.

I couldn't stop my self exploring the program and discovering some issues with Testing Triangles and logging them into comments sections while in hurry too.

I thought for a while on this program in the evening and felt that there are many similarities for this even though it's very very small when compared to the real world applications we test today. So let me take a re-look at this program and apply my test approach for the problem.

Step1: What is the Problem ?

We need to test a program that takes the three sides of a triangle and tell the user about what kind of triangle is it. Here is that Triangle program which has been written in Java Script.

Find the description from the post here

This version of the program takes as input three numbers representing the size of the sides of a triangle. When the user clicks "Draw" the program draws a picture of the triangle with the size of the sides shown in proportion and also displays the type of triangle.

Step2: Question the problem & get the required information for the Test.

The Testers first need to understand the application and the scenarios in which the same might be used.

So with this perception, let's re-look at the information available for the application. This is true that the above information provided for the application, acts as Requirements, User Manual and any other info we can call it as.

Like many applications that we test now, even this doesn't have clarity on the information provided. This is also one of the reason for me to call it as a classic example for testing. If we dig more into it the clarity on the information is missing and there are lot of implied requirements (at least from the developer perspective) /assumptions made by the developer.

It's not clear from the above description that

  • What is a Triangle and how to define the same ?
  • How many types of triangles are there and how to define each one of them ?
  • Are there any boundary limits for the size of the sides that makes triangle ?
  • Can any given three numbers make a triangle ?
  • etc..

Since the info is not available and the Triangles are very generic. Let's try to Google around the same and get some info to explore the application.

So get the info here, here, here, and here

Step 3: Sanity / Smoke Test for Triangle Program

By now, I know what a triangle is to begin with and how the same can be drawn. Let me do some sanity checks here.

  • For the Test Data of 1, 1, 1 as the values for three edges of triangle the output of the application is "Triangle Type: Equilateral"
  • For the Test Data of 2, 2, 3 as the values for three edges of triangle the output of the application is "Triangle Type: Isosceles"
  • For the Test Data of 5, 6, 7 as the values for three edges of triangle the output of the application is "Triangle Type: Scalene"

 

I have started with some very basic positive tests to make sure that the application is inline as per requirements. It's not good to test the application against negative tests to begin with.

 

Let's explore some more tests.

  • Try with 0,1,2 – Invalid – wow // might have checked for 0
  • Try with -2,3,4 – Invalid – wow // might have checked for -ve values
  • Try with 1,2,3 – Invalid – // what ? why is this invalid

For the Test Data of 1, 2, 3 as the values for three edges of triangle the output of the application is " Triangle Type: Invalid"

The Application says it's invalid. But as per the above spec it should be a Scalene Triangle since all the edges are different from each other.

The following queries came to my mind

  • Is this a bug with Application ?
  • Am I missing any more info that's required for the test ?
  • Can any given three edges make a triangle ?
  • Is there any logic behind the same ?
  • But it could have been good,if the application says why the data is invalid. I have no clue on this and it's a usability issue.

 

The general tendency that i see in many of the testers is to report it as a bug the moment they see some different behavior with the application and run into many discussion over the same. I have already blogged on it with a post as That's Expected Behavior and not a Bug. A little more depth into information gathering will be more effective.

Let's see why this test data is invalid for the application.

I got some more information again over the web on the edges of the triangle that will help me to understand the issue. And this is the logic behind the same. Get more info on this here.

In order to construct a triangle, the sum of any two edges must be greater than the third one.

 

So with the above data of 1,2,3 we can't construct a triangle and the data is invalid. But a error message here on why this is invalid from the application could have saved us lot of time in exploring the same.

One more test with 3,4,5

For the Test Data of 1, 2, 3 as the values for three edges of triangle the output of the application is " Triangle Type: Right"

 

Oh the behavior is different again. i am expecting of Scalene Triangle. Some more info via message could have been helpful for users on why the same has been labeled as that particular type. Might be the developer expecting all the users to have the domain knowledge.

 

Step4: Thumb Rules of the game

By now, we have capture a bit more info on the application & let's list the same here

  • Rule 1 : Sum of all the angles inside a triangle must be 180 degrees.
  • Rule 2 : In order to construct a triangle, the sum of any two edges must be greater than the third one.
  • In case of sides, they are called as equilateral triangle, isosceles triangle, right angled and scalene triangle
  • In case of angles, they are called as right-angled triangle, obtuse triangle and cute triangle

 

It's a good practice to update this section as and when we get the more info about the app behavior & fine tune the same.

 

Step5 : Black Box Testing on the Application

We have the following info as of now through above test observations.

  • Application doesn't have any validations for the input value to make sure weather it's a number or not .
  • The is at least one test case that has passed for all the types of triangles

Many testers with so much information available now for testing still trying to attack on the system with negative tests (people used to call it as negative testing) to uncover some issues on the first phase itself. Even though we uncover many issues there it won't be worth trying out the same without exploring the basic functionality of the application.

Let's explore the application with some more Tests

The side of the triangle must be a numeric value. So the application should allow only that kind of data. Application must draw the triangle with in the area given for the same.

  • Try with 6,8,11 – draws out side the box
  • Try with 3,4,5 – Right Angled
  • Try with 6,8,10 – Scalene- // Why so. why can't it be right angled ?
  • Try with 3,5,10 – Scalene // what ? Basic violation of thumb rules. it must be invalid. more over it just draws a single line and not a triangle
  • Try with 6,7,15 – same as above

There are couple of critical bugs here. For an input data which supposed to be invalid, treated as a triangle and other one is that it draws the triangle out of the box.

So there must be some goof up happened while handling the conditions on input data to satisfy them as valid or invalid. This has been proved now with the way that the above tests revealed the application behavior.

Let's do some code based testing now since it's a java script and the whole code is available.

Step6: White Box testing on the Application

Let's look at some important piece of the code.

if (this.s1 >= this.s2 + this.s3) {

 return "Invalid";

}if ((this.s3 == this.s2) && (this.s2 == this.s1)) {

 return "Equilateral";

}

if (Math.pow(this.s1, 2) == (Math.pow(this.s2, 2) + (Math.pow(this.s3, 2)))) {

 return "Right";

}

if ((this.s3 != this.s2) && (this.s2 != this.s1)) {

 return "Scalene";

} else {

 return "Isosceles";

}

The above code helps us to get the type of triangle based on the input data. Some observations from the above code

  • If there are no validations for the input values, then it's going to be a major problem. Think of the scenarios like (0,0,0) or (-2,3,4)
  • For this (this.s1 >= this.s2 + this.s3) condition we need to assume that the input data must be sorted from max to min being the s1 as max value and s3 as min value. Else this is going to be big blowup

Look at this bunch:

Triangle.prototype.setSides = function(s1, s2, s3) {
	sides = [s1, s2, s3];

 sides = sides.sort(); this.s1 = Number(sides[2]);

 this.s2 = Number(sides[1]);

 this.s3 = Number(sides[0]);

this.scale = 310/this.s1;

 this.scaledSide1 = this.scale * this.s1;

 this.scaledSide2 = this.scale * this.s2;

 this.scaledSide3 = this.scale * this.s3;

};

It's reading the input data, sort it and assign the same for the values for the edges. I am concerned about the sort() method here. It's a block box for us and need to explore on what it does. Other piece of does simple operations.

Let's ask the google again for some help here. Find some important reading here on the sort method.

Oh my god. This is the problem. It's doing a generic sort and not tuned towards the numeric sort. So this is the root cause of all the issues. It's such an issue that even a programmer might over look the same by it's nature

Find some info on how JavaScript sort works below from the link

Example

In this example we will create an array containing numbers and sort it:

<script type="text/javascript">
var arr = new Array(6)arr[0] = "10"arr[1] = "5"

arr[2] = "40"

arr[3] = "25"

arr[4] = "1000"

arr[5] = "1"
document.write(arr + "<br />")document.write(arr.sort())
</script>

The output of the code above will be:

10,5,40,25,1000,11,10,1000,25,40,5

Note that the numbers above are NOT sorted correctly (by numeric value). To solve this problem, we must add a function that handles this problem:

<script type="text/javascript">
function sortNumber(a,b){return a - b

}
var arr = new Array(6)arr[0] = "10"arr[1] = "5"

arr[2] = "40"

arr[3] = "25"

arr[4] = "1000"

arr[5] = "1"
document.write(arr + "<br />")document.write(arr.sort(sortNumber))
</script>

The output of the code above will be:

10,5,40,25,1000,11,5,10,25,40,1000

Step7: Summary:

I have taken a this approach for this application since it's simple to apply & explore in this context. It's good to always start exploring the applications by gathering information from all walks.

Keep getting the info, fine tune your tests and observe the application behavior. Set the base ground right and dig more and keep digging. You are bound to uncover all the important issues with the application.

Open Source Test Management Tools

In this post, i will share my views & findings with Open Source Test Management Tools. Usage of tools in the Test Management is becoming the basic need & It will be tough to manage the activities associated there with out any support from the tools.

 

The commercial tools in this segment are costly and may not fit into upcoming organizations budget. So i have been looking at Open Source Test Management tools. In the last week, I have evaluated some open source test management tools.

 

The following are my requirements for Test Management Tool

  1. Capture the Requirements

  2. Design Test Cases

  3. Map Test Cases with Requirements

  4. Link Bug reports with Test Case ID after the test execution

  5. Test Execution Reports

  6. Version Management for the Test Cases

  7. Search Feature

The following tools are evaluated after the initial screening.

The above tools work with Apache, MySQL & PHP. Both the tools looks promising and the Test Link has some additional benefits in-terms of better reports and linking with popular issue trackers.

Lessons to be Learned from the Bugs

In this post, I will be looking at Bugs  with an insight that helps testers to learn some new lessons on why the same might have occured. It's quite common that the testers are  blammed  for  all  the  missed out  bugs  in the system as if they are super natural powers to over see all the issues that are there in the system.

Bugs are there every where. Not just software applications, look at any system for that matter & there are issues wrt End User needs and the same might need to evovle over a period of time with the changing needs / requirements from time to time.

What is a Bug ?

It's tough to arrive at a generic defintion for the bug & people might have heated discussions on what is a bug & what is not. Mostly it's based on the context in which people are working. We do come across many bugs in our daily life while working with the tools that are needed for the day to day operations.

So in my context, Bug is something  that's unable (doesn't allow me) to satisfy my needs with the system.  What do to do ?

Capture the story around the Bug and not just steps to reproduce. Talk to the reporter and discuss on the scenarios used with the system that lead to the bug.Let's explore the possible options even though Tester validated the system early

New Test Scenarios for the Testers

  •  We mayn't even think of that scenario while validating the system. Add the similar test scenarios to the Test Suites

  • The scenario may not be logical (though it seemed to be for testers) for the user though functionally correct. Add to the similar scenarios to Test Suites

  • Might have been a compatability issue with a new environment that doesn't exist in Test Labs  

Reduce mistakes and improve test teams capability

  •  Might have been missed by a Tester. Check with the tester who performed the Test earlier and find out on why issue missed and the same marked as a pass even though it fails. Might happen through overlook also. Do more analysis here and try to reduce the same.

  • Might be over looked through regression tests. Might have failed and passed in the internal builds and finally breaked in the production system. Analyse the reasons here and improve upon on regression testing.

  • Make it a point to log the bug as soon as they discover the same. People might loose the same from their memory as time goes

Non Reproducible Bugs – How to deal with them ?

Last week, i had reviewed the bug reports submitted by my team & found that some of them are not reproducible. I am curious about where things went wrong & checked with the team.

Some of the Responses:

  • Look Venkat, this bug is not-producible always. So we have captured the log.

  • It does occur if we re-start the application

  • It takes good amount of time for the investigation

As a Tester, i have come across of situations where some bugs won't reproducible again and i infer that many of the testers might have gone through the same episode atleast once.

But then, Non-Reproducible Bugs are errors of the testers even though we may not agree. More over this is true for Technical Support & Testing functions.

It's tough for the Developers to work with such bugs and testers used to get lot of objections over such bugs. If the count is more, then it might spoil the relationships between testers and developers.

An Insight

I infer from my experiences that systems doesn't have the powers of human brain. It's tough to repeat the same mistake again from people since they are conscious. Systems doesn't have that much capability interms of thinking and they do perform the sequence in which they have coded for. 

How do deal with Non Producible Issues

Testers need to improve their skills inorder to reproduce such issues. The following might be a help.

  • Try to capture the story around the issue and not just steps.

  • Capture the complete Test Enviroment

  • Capture all the available Test Execution Results. This includes your test data, screen shots, applications logs, system logs, server logs

  • Need more patience (they won't occur easily)

  • Need more observation skills on the application behavior under test.

  • Narrate the story around the issue to the stake holders and to corner the issue.

  • Resources & Time Contraints might be an issue (More true for Tech Support). Bargain for the same

Conclusion

They are bound to take lot of time & resources in the process. It's suggested to reproduce each & every issue. We must explore more for the critical issues & re-produce them asap. In the process, we learn more too.  

Happy Testing.

The Role of Software Testing

This is my first post in the Bug Life Cycle Series. I need to talk about this because when it comes to the role of testing, it's not clear. The Role of Software Testing is often mis-understood across the different stake holders of the application development & this list includes testers too.

Testing is considered to be part of Quality Assurance activity since the initial days of Software Development and the same trend is happening as of now too. Even most of the titles like QA Engineer / QA Lead are associated with Testers even though they are not performing the role of QA.

It's good to capture the mission of Testing & align your test teams in that direction. Every one in the team must be clear on his / her role and see how the same is helping to achieve the mission of the team.

 

 It's good to note that

  • Testing is not about assuring quality into the systems because theTester is not a Quality Police.
  • Testing is not about targeting for Bug Free Product. It's just impossible since you can't build human brain into systems (Of course humans do commit mistakes).
  • Testing is not about fighting with the Development Teams. Don't act like the enemy of developers.
  • Testing is not about just looking at the documents (so called BRS, SRS, FRS) and writing the test cases.
  • Don't fight with Developers on the issues need to be fixed for the release instead write good report that reduce the time to reproduce and debug.

 

Testing is a process followed to make things better. It helps to take informed decision by providing the relevant information based on the context.

My teachers made me better by giving the relevant feedback at every stage on my performance. This includes nurturing the concepts, performance in the tests & week areas in the subject. This information helped me to identify the areas missed / uncovered and to improve upon.

Testers need to identify the critical issues with the system as soon as possible and make sure that the information supplied is sufficient to reproduce the issue. We need to supply the information on the presence of bugs in the system to the stake holders. The information should help the stake holders to take informed decisions.

The following list helps

  • Identify the different end users of the system and their interaction with the same.
  • Capture the important scenarios for each end user. It's good to note that we need to capture the story around the scenario and not just steps.
  • Talk to different stake holders including the customers (incase if you have access) on how the feature might be used & capture the scenarios.
  • Plan towards uncovering the critical issues of the system as early as possible

Final Thoughts

Focus towards what is import for the decision making. Try to uncover important issues first and provide the required information to reproduce and debug the same problem.

The Bug Life Cycle Series

I have been talking about Bugs in the Software Applications in my recent posts. They play an important role in Software Development & Testing. The biggest value addition is to uncover the critical issues of the system at the early stage.

I have already written some posts on the Bug Tracking front and find the list below. They talk about how to handle the Bugs, avoid conflicts & the lessons to be learned for the testers.

 

The above posts doesn't cover all aspects of a Bug.  I feel that it's better to write more on the Bug Life Cycle & explore the same.

The Bug Life Cycle series will have the following posts and i will be writing them in frequent intervals.

  1. The Role of Software Testing

  2. An insight into Bugs in the Software Applications

  3. Context driven information for Bug Reports – It's the need of the hour

  4. Life Cycle of a Bug – Different Stages in it

  5. Communicate the Value of Bug Reports

  6. The End Game

Stay tuned & check out the blog for upcoming articles.

Hey Testers, Communicate the Value of Testing

It's almost a month since my last post on this blog and busy with my upcoming release of QuickRules BRMS. I have been talking to the people around on the Software Testing and felt that it's not communicated well. Though there is enough information on this subject, i would like to describe my own version of the same here.

 

Testing is about making things better by providing constructive criticism based on the context (we can also say qualitative information and not being nice) at the right time and in the right direction too.

I like the phrase, "Testers, you are the headlights of the project" from the book Lessons Learned in Software Testing.

I have been thinking about this concept helped for the individuals. This revealed lot of crucial information and i hope this helps my fellow testers to motivate them & their teams.

There are many real life testers (incase if we need to list all of them) who contributed & still contributing a lot for us in every phase of life to grow and improve upon (fix the imp bugs among ourselves).Let's explore some of them below.

My Parents are the first testers in my life. They contributed invaluable information at each stage (Milestone release) of my life. Instead of saying "Sshhhhhh you can't do that, they used to tell me further implications that might arise". An insight into this tells us that it's not an order, but there is context based information for informed decisions.This helped me to stop for a while, analyze the information and work on the required steps to improve upon the current state.

My teachers helped me a lot by providing the constant feedback (just not being nice) through assignments, tests and covey the areas which are good and bad for me in the respective subjects. They are the best testers because they are the ones who taught the concepts and observed my execution towards the same.

There is a tremendous scope for the improvement, incase if we have acted upon the feedback at the right times.

My Boss at work used to evaluate (Test the Tester) me & provide the feedback on the tasks performed by me. This information helps to analyze to identify the next set of steps to be taken for the improvement.

If we look back, there are many testers around us providing the qualitative information to make things better and improve upon.

The Value of this information is tremendous since it came from people who are more experienced and passed through the current stage where we stand. The value lies in the fact that most of the successful people around, learnt a lot from others (learn from others mistakes too rather than your own) and they have become experts in their own fields.

How does this helps Software Testing

Software testing too comes under the similar lines and its role is to provide context driven information for the stake holders to make informed decisions over the application under test (AUT).

So as being testers, we need to provide the constructive criticism at each stage of the Development. If we look back at the above scenarios, the value addition is more because the people involved there have better skills over the context.

That being said, the current industry lacks skilled testers. The true value addition in Software Testing will be more, if and only if the people involved there have better skills over the context they working with.

Do share your views here or send them to me at venkatreddyc@gmail.com

Happy Testing…

Use Cyclomatic Complexity to determine the Risk and Test Scenarios

Cyclomatic Complexity (CC) is a software metric (mostly code based metric) used to the number of independent path executions in the application. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module.

It helps the developers to determine the independent path executions and base line unit tests that they need to validate. Using this, the developers can assure that all the paths have been tested atleast once. It's a great comfort for the developer and their respective managers.

It's better to write JUnit Tests for all these linearly-independent paths and integrate it with any code coverage tool. These reports help to focus more on the un covered paths and improve the code coverage.

It also helps to evaluate the risk associated with the application. The following are the results published by SEI and they are being followed widely to determine the health of the code base.

Cyclomatic Complexity      Risk Evaluation
1-10                                              A simple program, without much risk
11-20                                            More complex, moderate risk
21-50                                            Complex, high risk program
Greater than 50                          Un testable program (very high risk)

Explore more at Cyclomatic Complexity in Software Technology Roadmap from SEI.

Further Reading on the topic

Use metrics to evaluate the risk early in the cycle & improve your test coverage.

Happy Testting …

An insight into Bugs in the Software Applications

Abstract:

Bugs are there every where in the software applications. Almost every one who uses software applications for their day to day activities; do come across different kind of problems while working with them.  Each of these problems has different meanings to different people on it. There are many instances where in which, we (as end users of the system) do feel that how come they missed this bug, it's very important in this context (The context where in which the user operates).

Tester deals with Bugs every day and its good know about other people get affected with them. The list includes Customers, Stake Holders, Sales, Professional Services, Technical Support, Architecture & the Development team.

  

This is my second post in the Bug Life Cycle Series. Before going more into the Bugs and their life cycle, it's good to know, what it means to different people across the software application. Based on the contexts, the same bug might mean different things to different people. Do go through Role of Software Testing to understand my mission about Software Testing.

Wikipedia defines Software Bug as the following

A software bug (or "bug") is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.

Tester Perspective

Any deviation from the expected results of the test case will be treated as a bug in the software application.

 

Customer Perspective

Customer uses the software application to solve his business needs. Any problem while modeling a solution to the business need will be considered as a bug in the software applications. These problems can be classified into two. They are the list of problems that they can live with and the other is the list of problems that need to be addressed to solve the business need.

The second list of problems will be sent to the vendors of the application for the fix. Some times, customer sends only the show stopper problems for his business. It's true in the fact that as an end user, I will contact the vendor only if the problem is critical for me.

 

 

Technical Support Perspective

The Support Team classifies (though it's critical) the customer requests into New Features, Enhancement, Bug, How to & Enquiries etc with respective severity levels. The decision will be taken by validating the problem with the features in the product.

 

Developer Perspective

The feature is designed this way and all the cases have passed. The end user might be using some other scenario. Yes, Some times there are bugs in my code. But it functions well if we use the way the application has built.

 

Management Perspective

Any problem with the application will be treated as Bug if it has impact over the revenue and customer satisfaction.

 

Final Thoughts

It's tough to have same perspective across all the people (might happen in an ideal world). The bug for some one may not be the bug for the other person. However there are some set of show stopper bugs for which, the perspective will be the same.

Context driven information for Bug Reports

Context driven information is the need of the hour and there is a huge value associated with the same. It's good to capture the context driven information in the bug reports. My initial experiences with bug reports way back in early 2000 have taught many lessons to improve upon.

Bug reports used to capture what is the problem with the system familiar to the user (tester) who reported the same. People spend very less time to capture all the details required and there are many reasons for the same. I hope some of the upcoming testers will also be in the similar situations.

Some of the Reasons people quote here

  • We need to test more and less time to capture & write more information in the Bug Reports
  • It's tough to capture all the information required
  • System is complex & It's tough for the novice users to understand the bug reports
  • You know capturing all the info is process driven & it may not be worth of efforts
  • It some times boring activity to collate the info & push it
  • I can reproduce it on my machine if developer needs it.

This list can go on…

I hope you have come across this situation at least once in your career.

This is my third post in the Bug Life Cycle Series and it's good to know the different users of your Bugs and their context with them. The mission of your bug report is to provide details and context of the problem and convey the importance of it with a user driven stories.

Your bug report must be the voice of customer and it need play the role of an advocate against the problem. Bug Advocacy from Cem Kaner is an excellent source to begin with. If the bug report unable to specify the need of the context, then it's better not to write any report

It's good to explore & capture some of the following problems

  • Productivity
  • Performance
  • Usability
  • Migration
  • Stability etc

Try to link your issues with most suited functions listed above. It may not be obvious to other users in the system to explore & analyze the issues in that fashion.

There is another context associated with Bug Reports. That's with the stake holders of the project. The Bug Tracking system must give the right trends and identify the hot spots. Testers must capture the right kind of data to derive better valuable metrics over the bug repository.

Care must be taken to capture

  • Capture all the Test Environment details
  • Detailed classification on the feature. Classify to the maximum possible sub feature/component of the system
  • Clarity on Severity & Priority
  • Versions and Build Numbers (Affected & Fixed)
  • Bug Classification (Requirements / Design / Implementation etc)
  • Bug Types (Functional, Performance, Usability, Security etc)
  • It can go on…

The above info helps a lot to identify the trends in bugs and focus on the unstable components / environments.

Final Thoughts
Push the entire context driven information to the bug repository at least for a release cycle and observe the results. Check back with your repository to identify the trends and risk associated with the release and I am sure that it will be in the similar lines of end user feedback.

Happy Testing…

The Life Cycle of a Bug – Different Stages in it.

In this post, i will explore  different stages of the Bug from it's inception to closer. The Bug has been found and logged into the Bug Tracking System. It's my fourth post in the Bug Life Cycle series.

  1. The Bug has been found and logged into the Bug Tracking System. It will be treated as New Bug in the System.
  2. The Bug will be assigned to the concerned Developer for a Resolution.
  3. The developer looks in to the possibilities of the resoultion & takes a call on Resolution by fixing it or differing over the information provided.
  4. Tester validates the resolved issue in the build & checks for the regression scenarios over the fix.
  5. If the issue found fixed, then he choose to Close the issue else he / she will Re-open the same.
  6. The Cycle follows again for the re-opened issue till it get's closed.

Bug Life Cycle

It worth doing the following activities

  1. Capturing the required and re-usable info to the Bug Report at it's each stage.
  2. Check for all the closed bugs of Severity 1 & 2 against final build for the release.

In the next post, I will share my thoughts on the useful metrics over the Bug Tracking Repository.

Happy Testing..

Wednesday, December 29, 2010

Database Testing

Today database becomes as engine to many of the enterprise applications. System would be affected badly if the transactions and queries produced the false conditions. Due to lack of database testing, applications may go to dead lock, data corruption and data loss conditions. These type of issues would take more time to identify and fix. Database testing includes verifying stored procedures, table indexes, exceptions, schemas and compatibility.

Different types of Database Testing

  • Structural testing
  • Functional testing
  • Boundary testing
  • Stress Testing

Few Sample Scenarios
  • Creating an user account from GUI - How would you ensure the details are stored into table correctly?
  • Executing stored procedures in different conditions like valid and invalid conditions.
  • Varying data definitions - The data type and length for a particular attribute may vary in tables though the semantic definitions are same. Example: Account number declared as Number ( 9 ) in one table and the same as varchar2( 11 ) in another table.
  • Varying data codes and values - The data representation of the same attribute may vary with and across tables. Example: Yes or No may be represented as "Y", "y", "N", "n", "1", "0".
  • Misuse of integrity constraints - When referential integrity constrains are misused, foreign key values may left "dangling". Example: Employee record deleted but dependent records not deleted.
  • Nulls - Null may be ignored when joining tables or doing searches on the column.
  • Inaccessible data - Inaccessible data due to missing or reduntant unique identifier value. Example: Uniqueness not enforced.
  • Incorrect data values - Data that is misspelled or inaccurately recorded. Example: Indra Nagar - Indra ngr.
  • Inappropriate use of views - Data is updated incorrectly through views. Example: Data is properly fetched from the database but first record or last record is not displayed

QTP - Smart Identification

Sometimes back, I was in a QTP interview panel. Most of the candidates do not know about smart identification. That's why, I thought to write to this post.

Need of Smart Identification
Smart identification is a technique in QuickTest Professional. It is used to identify the objects, even though few mandatory properties are changed at run time.

Smart Identification Overview
The Smart Identification dialog box enables you to create and modify the Smart Identification definition that QuickTest Professional uses for a selected test object class. When the recorded definition for an object does not enable QTP to identify an option, QuickTest Professional uses the smart identification definition (if defined and enabled) to identify the object.

Smart Identification uses two types of properties:


  1. Base filter properties: The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link's tag was changed from <A> to any other value, you could no longer call it the same object.

  2. Optional filter properties: Other properties that can help identify objects of a particular class as they are unlikely to change on a regular basis, but which can be ignored if they are no longer applicable.


To know more about Smart Identification, You can see the QuickTest Professional Help for following topics:

  1. About Configuring Smart Identification

  2. Understanding the Smart Identification Process

  3. Reviewing Smart Identification Information in the Test Results

  4. Walking Through a Smart Identification Example

  5. Step-by-Step Instructions for Configuring a Smart Identification Definition