Archive for the ‘Testing’ Category
I asked one of my students about the homework (assignment) I gave previous day but she said that she could not continue testing the software as the software and the requirements were confusing. She was frustrated with the whole thing that she could not understand what needs to be done next. She was disappointed and she stopped testing the product.
I understand her situation and reasons for frustration because I have worked in projects where everything looked so confusing, there’s always the time crunch and managers expect deliverable because client is sitting on their head. This is a typical situation in testing projects. And this is a same story of many testers who get confused, frustrated with requirements and with products. And no wonder why the poor quality product gets released in market.
How do you motivate yourself when you are in such situation?
It’s a fact in software development that requirements are never written clearly & completely. It is not possible because technology & business keeps changing every second. So, how do you expect requirements will always guide testers and developers in right direction? Secondly, machine and programming languages has limitations and that’s the reason new programming languages and frameworks keep emerging every day. So under such limitations, developer writes program on incomplete requirements then imagine how the quality of the product is going to be like? Your client is not aware of the quality of product. They have invested lot of money to build the product.
If I have to place a tester in such a chaotic situation then she should be the one to provide fact based information about product’s quality. She knows what product can do & what it can’t. She gives direction for further development and helps in making important decisions about the product. Testers help client, manager and developer to improve quality of the product. Without testing, software could turn out to be a nightmare not only for the end user but also for the vendor.
Testers work like a light house because they give timely feedback and appropriate direction. A tester has most important and critical role to play in software development. All your stakeholders look for information which guides them because they cannot see what a tester can see. They are dependent on you like a blind person so if you stop testing or get de-motivated due to the situation then who else will guide them? Who will tell them the truth about their software? So don’t give up so easily because you have not yet come up with your best testing solution. You have not come up with your best test technique which is uniquely designed for this project. You need to strive for better testing that can only happen when you do not lose hope, when you do not lose confidence, when you do not stop trusting your testing skills.
Your service would make a lot of difference to your software’s quality, so keep providing your service honestly and do not stop!
“I slept and dreamt that life was joy. I awoke and saw that life was service. I acted and behold, service was joy” – Rabindranath Tagore
I believe Bug Report is equally important like Test Cases, Test Plan or Test Strategy.
Let’s say, you have a great test plan and strategy for testing. And your testers are also good at writing test cases. You found many important bugs which makes lot of sense to fix them. But what is the point of having excellent test plan if your bug reports are getting rejected? There may be various reasons to reject bug reports but the Number one reason as per my understanding is lack of clear and precise information about bug.
Cem Kaner rightly said that bug report is ultimate product of testing which is like tester needs to sell bug reports to their stakeholders.
I worked in and as a triage team in one of my previous project and realized that it’s extremely difficult to deal with a report which has inadequate information.
Below sentences in your bug report may trigger rejection from your stakeholders:
- It is not working properly: Imagine how receiver of your report would take up the meaning of this statement. I get confused with this sentence. It does not tell, ‘how the feature is not working?’ It does not tell what your oracle is? It does not give any clue about bug. Developer spends lot of time in reproducing. They would then pick their own meaning about the feature which is not working properly. Based on this understanding, developer would fix the bug. Tester again reopens the same bug because something else got fixed. Isn’t it wasting crucial time of your project?
- It is not properly displayed: Sometime testers (including me) find it difficult to describe what they have observed to put it in description. And it soon becomes the main reason to add words like ‘something is not displayed properly or working properly’ which come as a rescue line for most testers but we are missing the importance of bug report. Bug report is for making things easy rather than complicated or time consuming.
- Take any input to reproduce bug: Computer has innumerable options available to give inputs to the software. And every individual’s imagination is different and subjective. She can’t think of same inputs as you entered when you encountered an error. This may lead to assumptions which may not be fruitful with respect to the timeline & criticality of the project. I think one of the reasons of projects being critical is that manager focuses on processes, plans and pay less attention to enhancing employee’s skills which is key thing in project.
- Avoid these kind of statement in your report because they are ambiguous
- Make sure that you write in such a way that developer would understand only what you intend to say about a bug
- Write clear input & output
- Write what you observed
- Do not let your bug sit in stakeholder’s imagination else it will never be fixed.
It’s in your hand to convince your stakeholder to fix your bugs through your clear and precise bug report. So write carefully!