Reporting bug in more polite way

Today I had an argument with two developers in our lunch table. The argument was related to Bug reporting. I am always tried to see a bug in developer’s perspective. So my development friends are always keen to discuss there QA related matters with me.They were argued about the polite bug reporting ways.

One of our QA team members has reported a bug and in the last line of the bug description she has said “This conclude that the system is not stable”. I will never agree with this kind of comments in bug description. The development guy told me that’s why QA department is there. If the system is stable in the initial step then we don’t have to worry about the client releases. He is correct. Unfortunately I don’t have a way to advise this team member.

I believe developers are working hard to make the things working. We need to respect to there thinking power and effort. But I don’t accept doing careless mistakes in project. Finally I agree with my development friends regarding this matter. Get the bug fixes done from developer is an art that should be practiced by QA. We need to find bug but need to report those in very polite way without hearting developers.

Some Useful links for Software Testing Automation

Links to find resources for automated testing

Test Automation Snake Oil - James Bach
http://www.satisfice.com/articles/test_automation_snake_oil.pdf

Improving the Maintainability of Automated Test Suites - Cem Kaner,
Quality Week ’97.
http://www.kaner.com/pdfs/autosqa.pdf

Techniques and ideas for automating software testing - Bret Pettichord
http://www.io.com/~wazmo/qa/#test_automation

Architectures of Test Automation - Cem Kaner
http://www.kaner.com/testarch.html

Totally Data-Driven Automated Testing - Keith Zambelich, SQA Testing
http://www.sqa-test.com/w_paper1.html

Seven Steps to Test Automation Success - Bret Pettichord, June 2001
http://www.io.com/~wazmo/papers/seven_steps.html

Test Automation Frameworks - Carl Nagle
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks

Using Silk Test as a Automation tool

In general I am not a huge fan of the Prepackaged Test Automation Suites, however if you are going to use one I find that with a few exceptions Silk is the best one to have.

As far the best approach, Use a Keyword driven Test Methodology.

This is one step beyond a data driven approach and truly minimizes the maintenance overhead of the test automation infrastructure.

With Data Driven testing you have a test case which is a series of steps which are set by the code, but the data entered at each step is parameterized so that you can run the same test multiple times with different data.

Keyword driven testing takes the sequence of the steps themselves and removes them from the code the same way that data driven tests removes the data from the code.

In Silk you do this by controlling the names of the objects in the frame file. Come up with a naming convention so that you can predict the name of any object based on the window it is in, it's object class, and the user understandable name of the object.

You then "teach" your code how to associate keywords to specific objects, then you build a database or spreadsheet format that lists keywords that instruct the script what steps to take.

So for example, a simple login screen, that has a Username field, a Password Field, and a Submit Button, the objects would be named

Login_TextField_Username
Login_TextField_Password
Login_Button_Submit

One "row" of data in the test data would define one step in the testcase, it requires 5 pieces of information, The screen name, the object class, the name of the object in the screen, the action you which to take (generall this will correspond to a method available to that class, however it can be something custom too), and the data to apply.

The data for logging into the system would be


Row1

Screen - Login
Class - TextField
ObjectName - Username
Action - SetText
Data - ABC123

Row2

Screen - Login
Class - TextField
ObjectName - Password
Action - SetText
Data - "Passw0rd"


Row3

Screen - Login
Class - Button
ObjectName - Submit
Action - Click
Data -


The Automation code will then read your test data repository to not only get the data to use but also the sequence of steps to follow.

GUI Testing Checklist

GUI Testing Checklist

Here are some sites that give comprehensive checklist for GUI Standards. Hope this will be helpful to all newbies in testing world.

http://www.sqatester.com/documentation/GUIchecklist.htm

http://www.methodsandtools.com/archive/archive.php

http://www.methodsandtools.com/archive/archive.php?id=37

http://usability.gov/pdfs/guidelines.html

http://usableweb.com/#Keith%20Instone'sSite

http://www.humanfactors.com/downloads/guistandards.pdf

http://www.maskery.ca/services/ui_design_standards.htm

http://www.iie.org.mx/Monitor/v01n03/ar_ihc2.htm

Measuring of Adhoc Testing

One of the possible ways to measure Adhoc testing is SessionBased Test Management. It means that you should define sessions; each of them should contain suggestions about what should be tested. Session looks like a mission, not like a Test Case. Then you split sessions between testers and they do their work. After testing done he prepare report which should contain information like this:

Session Name
Tester Name
Start Time
Duration
Test Design and Execution
Bugs investigating and Reporting
Session Setup
Test Notes
Test Areas
Risks
Bugs list
Issues list

After you have collected reports from tester you can measure their productivity, because you have enough data.

Also you can perform test planning because you can define all needed sessions (e.g 50), estimate how many sessions can be executed per day (e.g. 5), analyze how many perfect sessions you have (e.g. 70%) and you know how many testers will do this job (e.g. 7)
So, it is easy for now to estimate overall time


50 / (5 * 7 * 0.70) = 2 days

Automated or Manual Testing

"Better" implies a value analysis. Some folks are good at manual testing andpoor at automated testing simply due to their make-up. Trying to trainsomeone who really is not cut out to be an automated tester will yield poorresults. A good automated test engineer needs the predisposition of atester, but also the mental composition and interest of a developer.Finally, in the U.S. at least, automation test engineers are normally paid apremium, averaging 20% more in salary, than manual testers. On average,remember, so there will be exceptions in industry segments. The reason? Theyhave to know some programming and development.Regarding the relative stability of employment you think manual testersenjoy compared to automation types, I assert that is domain specific to adegree, but more probably company specific. If you work for a company whodiscards testers proficient in Tool A when they bring on board Tool B, thenyou need to look for a job elsewhere. The management of such a company is ingrave need of a clue. The specific techniques for Tool A and Tool B will bedifferent, but the approach to test automation, the design and architecture,the discipline and engineering of it, is directly applicable regardless ofthe tool used. And that experience is more difficult to find in employees. Ican teach just about anyone with half a brain (which, from my experience,excludes some half of the candidates) how to use any tool to a basic anduseful degree of proficiency. Only a few will ever have what it takes toprogress to intermediate proficiency. Most companies choose one solution andas that improves or changes, they make sure their employees improve andchange too. It is an investment that is in the company's best interests. Ifthe underlying technology of the product radically changes, then the testapproach -- and tools used to implement that approach -- probably will haveto change as well. Client-server vs. web browser-based would be a commonexample. Moving from C++ to Java is another example.Regarding domain specific cases for stability, it is the knowledge of thatdomain and the prior product versions that makes the tester valuable morethan the fact that the tester is a manual tester or not. I worked for acompany where the QA testers pretty much had to have the equivalentknowledge base in geology and petrophysics of at least a Master's degree.Several were PhD level. THAT knowledge and experience of product, or how theuser community used the product is what made them employable at thatcompany. How they tested the product was less important.One last thought: many companies are sold a proverbial "bill of goods" bysaavy sales reps from the automation tools vendors and are convinced Tool Ais the complete and end-to-end solution to all their testing challenges.When it doesn't pan out, due to lack of training, lack of organization andarchitecture, etc. etc., the company management tends to want to jettisonthe tool that let them down. The tool users often are jettisoned as well, aspart of a failed project. This happens all too often. Then the next "silverbullet" be-all and end-all Tool B sales rep comes along and convinces thecompany that IT'S product was what the company should have had all along.New tool and new tool users come into play. Normally, the same resultoccurs, because it is the test management of the company that doesn't knowhow to implement test automation, and the same guys are there time aftertime after time, making the same mistakes over and over.

Relation between KLOC & Test cases

KLOC means Kilo Lines of Code means 1000 Lines of Code

so KLOC = 1000 LOC
10 LOC = 1 FP ( Functional Point)
we can design 3 test cases from each Functional Point

1 FP = 3 TC ( Test Case )

1000
------- = 100 FP
10

so 1 KLOC = 100 * 3 = 300 Test Cases ( we can write approximately ....this is according to my comp test metrics )

Getting the first break in Quality Control

Please let me begin with a clear note that I am writing these for candidate who are well deserved as QC professionals. They have systematically learnt QA process, and are prepared for this break. Please don’t misunderstand that I am writing this for people who think QC is a stop gap. A good QC professional is best in his breed and has selected this career not as the last option, but as a career of his choice.

I have found that approaching directly to a company with no experience has often been fatal. If you are extremely lucky, you may get pass the HR scanning but the QA manager will have a high probability of not selecting you as he also is answerable to someone. He would not like to gamble when there are other more experienced candidates.

I have found that if you want to get a jump start in your career, please approach the small consulting firms who are second level vendors. They often have more time and are more willing to listen and interview you.

Once you get on to their list, they often can you get a good break.

This is how it works: When IT departments or companies need people in rush for short medium or long term projects, they often approach their top vendors to produce skilled staff for the same. They often rate these vendors efficiency on a quick turn around not to mention also pay them a butt load of money. They assume that skilled man powers could be bought in supper markets.

So these vendors to prove point, as they also have to compete with others, resort to these second level vendors. These are the times when your consulting firm whom I am referring as second level vendors, pushes your resume to the direct vendors. In these cases resume scanning less stringent and sometime even an informal interview can get you in.

Once you are in it is up to you to prove your worth.

I am not saying this works always but I have seen many people getting their first break in QC in similar fashion.

I know many of you may not agree to this. But if you have other suggestions, please go ahead so that the candidates who are looking for their first break can use your help in this regards.

Of course networking, forums, groups etc helps too.

Worst resort, get into a company as an intern. Trust me, if you are good in your job, it won’t take time for you to be recognized and rewarded appropriately. There are always shortages of good QC personnel.

How to be a Good software Tester/QA Engineer

  • Be a self learner about new technologies and new QA methodologies and keep an eye of development techniques as well.

  • You should look at the products or projects that you have recently released and find out if you missed any defects (you will learn more about testing)

  • You should be learning new techniques and studying new tools that are applicable.

  • You should get off your butt and show some initiative.

  • Dealing with developers to get the bug fix of other kind of QA activity is a skill. Try to understand the developer attributes and work according to that.

  • Learn how to write effective test cases, Minimum number of test cases with maximum test coverage

  • Never judge you team mates or rank them with you. Think that all the team members are equal since all of them working for same company and same company goals.

  • Try to learn some programming languages and to some simple code, which will help you one day to be a good QA manager who understands Greek of developers?

  • You should be experimenting with back-up and restore tools for your test lab
    such as Ghost, Drive Image, and Frisbee



TopOfBlogs Technology Blogs - Blog Catalog Blog Directory Software blogs feeds2read