I‘d like to talk about software testing and a little bit about Rapid Software Testing. You see, it’s very important when you pass the test information to the right people, at the right time. We already know what testing is and how it is done.
During testing we find out some information, which is basically the meaning of the testing. When we find a bug, but we keep it somewhere in the shelve so that no one can find it, it is not a test! I do not know what it is, but it is definitely not a test. And when is it the right time to say about the bug? Whom to tell about the bug? These are the most important questions.
Let’s imagine the following situation; Your team has been asked to test the product after the release. They asked you to make it within 6 hours, because after that the owner of the company must present the product to the investors.
You start testing and at the very beginning you find a very important bug that is related to another functionality of the product that the owner of the company will show to the investors. You just write down the bug on a piece of paper, in order to add it on Jira at the end of the test, then send it to the PM, and only then go to the owner and inform him about the bug. Instead of 6 hours, you have spent 5.5 hours, you finished the testing, and you found some 3–4 important bugs, one of them is very serious, the other 2–3 are nothing special and you put on a happy face and walk to the boss’s room to inform that you have finished the testing and you have found a bug. When you get to the boss’s room voilà, the boss has already gone to a meeting with the investors because he thought that for 5.5 hours no one has approached him and told “boss, we found a bug!”, so he decided to go outside earlier & to breathe some fresh air, and then walk peacefully to meet the investors.
Besides, when he entered the room earlier that day and asked “Guys, is everything okay?” you were absent, in the toilet at that moment. The boss goes to the investors to present the product and surly everything goes wrong. The boss comes back pissed off and locks in his room.
It would not be this dramatic if you kept a simple working rule; to deliver the necessary information to the appropriate people as soon as possible. What would happen in that case? You would find the bug, you would quickly inform the PM, the boss, the team lead. They would ask relevant people to correct the mistake, the corrected version would get back to you, you’d check it once again and yahoo! Life is wonderful!
The moral: It is very important to check the right things at the right time and to inform the right people about it.
How to find bugs?
In order to be able to check the right things you need to be well acquainted with the product. Being familiar with the product does not mean to know the functional description of the product; what it has and how it works. You surly need to know all of that. But there are some other important things that you need to know. For example, who are the users of your product? What problem does your product solve for these people? What skills do these people have? How do they use your product? When do they use your product?
Let me bring some examples.
In the Silicon Valley series, one company creates a wonderful product that has more than 500,000 downloads in a few days, but the number of active users does not reach 20,000. And what do they find out? People don’t understand the product, but they need it very much! It just needs to be more comfortable and understandable for the users. Every day several innovative products enter the market and after a few days they disappear from the market precisely because they are very incomprehensible, difficult and can not solve user’s problem, making their lives easier & increasing people’s comfort.
We test programs that are used by people of different classes, working in different fields, with different preferences. One of our products is used by taxi driver Gurgen to pay for the parking, and mister Sargis to do shopping at the supermarket, or Hakob, who owns a farm in odnklassniki.ru, iOS developer Sergey, a director of a company Mr. Trampyan, organ teacher Shavarsh, swimmer Karen, key maker Samvel and many others, so we must take into account that the program must be user-friendly and easy for all of them. We must take into account that this program should be understandable by everyone.
The users of the product might be Congressman Jay McClaus, hunter Steve Jochlach, lonely woman Kate Seylar, collector Anthony Krushwell and driver Barry Lihatski. We need to be able to give our partner information about all the comforts and inconveniences of his product. In order for us to be able to do that, we must be able to understand its users, we must follow the developments in the field, the trends of the field. Under no circumstances should we limit ourselves to testing what is written on the ticket. We must be able to ask the ticket-writer the right questions to be able to check it. And how to do it?
Ask the right questions!
We must ask the right questions. Asking questions should not be an end in itself, to say “oh, I’ve asked a question, now I can eat my burger”. The meaning of questions, the basis should be the received formation of product models with the given answers. When we model a product, we understand the product ourselves, we understand the product testing cycles, the product testing methodologies, we can talk about the product testing dates, we can form an idea of the connection of product functions. Starting with right questions, lets us see the connections and even discover them.
Having the product model in hand, we can predict the time we need for product testing. We are often asked, “How long will it take to check our website?” There are several ways to evaluate time. Based on our relevant experience, of course, we give unsatisfactory answer to a person who asks such questions, so that he/she goes away from us, and in more real cases we model the product and based on the model we are able to give an approximate deadline.
And what to do when there is no one to answer our questions?
We need to project our experience to answer how much testing will it take us. Of course, it rarely happens when we face several identical projects, that’s why we project our experience and make an approximate prediction. You should never be afraid to ask questions. It is better to ask a simple question than to miss a simple bug because of your lack of knowledge.