softwaretesting

Dec 15 2008   9:55AM GMT

Mr Tester, please feel PRIDE in doing what you are doing at job

Posted by: Jaideep
software, Software testers, software development, softwaretesting, tester, Project Development

Hey my dear Tester, what you are doing is a tremendous effort in streamlining the business of your organization. It is you who understands the business requirements of your customer, learning their business rules, understanding the product built by your development team to cater to those needs, testing the product and finding the lacunae in the product, helping developers to understand those lacunae, and finally testing those fixed lacunae.

So you are playing the key role between the two extremes, the customer who is demands, and the developer, who supplies. It is important to mention here that your role is the most vital bond between the two. Infact during testing, you have to act as a dummy for customer, and examine the product as per customer’s perceptive. Now let us look at the strategy following which you can feel PRIDE in your work, and make your organization realize that. First of all testing should be a mission for you and for each of your mission, you have to be passionate. Your passionate mission every time is to find out the holes in the pot called the software product. Work with development team in collation rather than isolation and move together towards the path of reconstruction. Drive side by side rather than driving in the opposite directions. During development and testing, you and the developer have to work in a manner that if one reaches out a hand, the other clasps it. The final goal is not to pinpoint each other mistakes or shortcomings, but is to find them out and fix them to deliver a strong product to your customer and ultimately expanding your organizations business.

The product has to have the firm roots, and minimal changes, for which right understanding and development by the developers is important. You have to teach this lesson to your developers that any wounds even after complete healing will always leave scars.

Be proud of yourself, be proud of your work, and be proud of your organization… always…

Your work should speak that you are feeling PRIDE in your job, and last but not the least… make your organization PROUD of you. Testing is really a challenging job, and it is you who is doing it. Your organization already feels that you are the best resource available for this purpose.

Nov 28 2008   9:55AM GMT

How to Create, Build and Maintain Harmony between tester and developer

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software design, Software testers, SDLC, software qa, software deployment, developer, softwaretesting, STLC, tester, software requirement

‘Create’ means the first time effort to generate a harmony between a tester and a developer working on the same project. ‘Build’ is the next stage after create to harmonize the professional relationship between a tester and developer. This step will bring the strength in the relationship. ‘Maintain’ is not only the sustenance of this healthy relationship which can be termed as ‘sweet’ harmony, but also calls for an effort from both ends to ‘keep on improving’ this bonding. To create, build and maintain an everlasting harmony between the testers and developers, here are some tips:
1. Share: Sharing is a two way process. Both the sides need to share equally, transparently and openly. The development team needs to share the customer requirements, business rules, relevant documents, design plan, coding, system built. On the other hand the tester needs to share his observations on all these, and the results of his testing. Share problems, thoughts and success together.
2. Raise an Alarm: Tester and developer require raising an alarm in case of any shortfall in above sharing required from both ends. Developer also needs to raise an alarm in case of inadequate testing or if testing is getting delayed due to any reason.
3. Act Jointly: Tester should sit with the developers while they are on job i.e. designing system, and similarly developer whose product is being tested preferably should sit with the tester while he is testing the product. This support will not only strengthen the process and product but will make it more secured.
4. Avoid Protectionism: On the work front, be it of a developer or a tester, it is important to prevent the spread of protectionism and to promote transparency or openness across the organization. If this is not handled properly, it may lead to depression and incoherence across.
5. Accept Framework: Accept each other’s work framework and respect it by heart.
6. Resolve crisis: In case of any crisis on any front leading to adverse effect on the project, take all necessary measures jointly, timely in a coordinated manner. Be more than willing to act in this regard.
7. Tester is a bridge: Tester is a bridge between developer and customer for the purpose of smooth and defect free delivery of product to the customer.
8. Be a great contributor: To achieve great success, be a great contributor in your respective fronts.
9. Encourage: Encourage each other.
10. Remember: Always remember that you have joined hands to achieve a common goal. A good harmony always brings in the ‘success’

Nov 26 2008   10:11AM GMT

New Release for testing – a tester’s paradigm

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

A new software release for testing could be a new product or major changes in the existing software. In either case the bugs report should have a new version number for control purposes. Although in case of a new release of existing software, the existing bugs can be referred to but that does not mean to check only for those bugs.

Anyhow before the tester starts testing of this new release (or for that sake of any new release!), (s)he has to make sure of three certain activities:
1. Clinical review of the testing requirements
2. Known bugs (in case it is a chain release) fixed
3. Scope – customer requirements, software requirement and business rules

And above all now tester’s task is to ensure that the software (re)built is completely aligned to the above three.

Nov 17 2008   10:15AM GMT

SDLC-V: Software testing

Posted by: Jaideep
software testing, software, SDLC, softwaretesting

Software Testing is the process to ensure a bug-free, fully functional software meeting all customer requirements. Testing starts right from the development stage. The developer himself is responsible for unit testing, smoke testing and code testing while he is building the code. Once different units, built by different developers, take the shape of a functional product, a need arises to test the product as a whole, each of its unit, each module and sub-module. This part is handled by a separate team known as QC, QA pr Testing Team.

Software Testing is very important to ensure:

1. It is meeting all customer requirements
2. All business processes have been built appropriately
3. All business rules are working fine
4. Functionally the product is ok
5. Each unit, sub-module, module and finally the product as a whole is meeting all software requirements
6. Exceptions are handled appropriately
7. User manual and software match
8. Software requirements, User manual and software match

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 8 2008   10:35AM GMT

Bug Management - Major Concerns being felt across the Globe

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

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

These concerns could be grouped as below:

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

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

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

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

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

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

7. Bug management leads directly to bug avoidance.

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

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