Tuesday 13 September 2011

How to be an effective software tester

Every one wants to be the best and do the best to come up in life/career etc. To achieve this many follow different methodologies and strategies and they come up in life paving a way for those who want to come up.

Software Testing is a vast field and whoever opts for this field also practice certain principles to become a good tester. This question often ponders in everyone’s mind even after spending few years into software testing and leading teams on different projects as to how can I become a good tester. Most often people acquire knowledge by going through various articles on internet, experiences, stories of those successful and many more. With this everyone reaches to a common conclusion that for any one to be successful there are some methods or strategy to follow.

Any one coming fresh into testing have many questions about software testing, what it is all about and the actual work that they are going to perform. As fresher in this field, you should be aware of certain facts in the software testing profession as an individual.

The common information or tips as generally called, below will certainly help to advance you in your software-testing career. These are not only for fresher’s but also for experienced testing professionals too. Applying these in your career you will mover forward in your career and will not regret for what you are doing.

Software Testing is a very demanding job because one needs to be vary cautious, logical and come up with different ideas and logic than that of those which are common. Testers should think differently and do things in a different way to see that bugs don’t go unnoticed and always try to break the system.

The following information will definitely help you to achieve good results in your career.

Knowledge of the Application under Test.

Many at times in most of the companies they get the application deployed on the test server and are asked to test the application and most of the tester do an exploratory testing to know the application. This is also based on the deadline and the process being followed in the company.

The best practice is not to start testing without understanding the requirements very clearly.
If an application is tested without adequate knowledge of the requirements it is very difficult to determine whether a program is functioning as desired and as per the design and will not be in a position to tell if required functionality is passed or missing.

Clear knowledge of requirements, before starting testing, is a must for any tester and the lead’s responsibility is to make sure that the tester has got enough knowledge of the system under test.

It is always said prevention is better than cure and it is also true in software development that it is better to know any missing issues and fix them than to find those issues during testing and fix them.

Acquire Domain Knowledge

It is always good if we acquire thorough knowledge of the domain on which you are working.

Being well versed in the domain will help you to give good suggestions and also solutions for any issues being faced because of the bugs.

It is always appreciated by the test manager/project manager for your suggestions which has an impact on the application and also if certain features can be fine tuned

Most of the time we as testers feel that our responsibility is to only logging the bugs but it is appreciated if solutions are provided and this will earn respect amongst the colleagues. Good domain knowledge will also help you to design better test cases with maximum test coverage.

Do not come up with Assumptions while Testing

It should always be kept in mind that every application under test has bugs and it is our responsibility to find bugs potential of breaking the system. Testing should not be started assuming that there will be no errors.
From a QA point of view you should always look for new bugs, different bugs, hidden bugs etc. no bug should be left unnoticed whether it will be fixed or not.

Keep updated about new technologies

with the advancement in technology there are constant changes in the technology we use and there requires new techniques even though old testing techniques still play a vital role in day-to-day testing, but it is always good to try to introduce new testing procedures that work for you.

Most of the time we rely on book knowledge and try to follow the procedures mentioned in them and most of the time we do not achieve results. One should be practical and come up with new ideas and techniques which will work for a particular system. They may work amazingly for you.

No one can certify after testing that it is a bug free application

No wonder how many rounds of testing you perform; you can’t guarantee a 100% bug free application. There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions. Put your best efforts doing good work.

Behave like an End User

This is the most important piece of advice we as testers should think and behave like the end user i.e the one who is going to really use this application. I don not say that you should not think technically but think like customers or end users and beyond. Test your application as an end user in different permutations and combination's. Do all sorts of transactions, navigation's, insert values, delete values etc and see that any way you do a function it should give the result same for different types of test carried out for the same functionality. Think how an end user will be using your application. Technical plus end user thinking will assure that your application is user friendly and will pass acceptance tests easily.

It is Not Possible to have 100% Test Coverage

Most of the time we think of having 100% test coverage with all the test data we have but most of the times we may not near it and don’t obsess about 100% test coverage. There are millions of inputs and test combination's that are simply impossible to cover instead use different testing techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes and achieve the result.

Build Good Relations with Developers

It should always be remembered that as a tester we are there to bring quality into the application and should not become a hurdle in the SDLC or for the project instead we should behave as building blocks and should fillthe gap. As a tester we communicate with many other team members and specially the developers. There comes many times where we don’t agree upon each other on different issues and most of the time there exist a friction between the test team and the development team. It is by experience and skill to handle such situations without harming a good relationship with the developer. If you are wrong, admit it. If you are right, be diplomatic. Nothing should be taken personally. After all, it is a profession, and you both want a good product.

Learn From Mistakes

Every one of us knows the mistakes we commit while testing and if one says that there are no mistakes then there exists a doubt whether they are testing hard enough! You will learn things as you get experience. Use these mistakes as your learning experience. Try not to repeat the same mistakes.
It hurts when the client find any bug in an application tested by you and the creditability of the tester is at stake. It is definitely an embracing situation for you and cannot be avoided. However, don’t beat yourself up. Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future. If required, change some testing procedures you are following.

It is not your fault if some bugs are not fixed.

Some testers have assumptions that all bugs logged by them should get fixed. It is a wrong assumption based on the severity and priority of the bug and needs of the project the bugs gets fixed or will be carried over to the next phase saying that these are known issues. It is a good point to a certain level but you must be flexible according to the situation. All bugs may or may not be fixed. Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix.

No comments:

Post a Comment