Let's say you, as a software tester, are being presented with a technical solution.
You will probably have questions, sometimes lots of them. Some are for your understanding, some as a critical thinker.
Here are some tips for asking (or not asking).
To ask or not to ask? This is the (first) question
One of the problems with asking a question is that it causes you to expose your ignorance of a particular subject and thus feel bad about yourself (most often at the inner level, others will not mind).
The thing is, we're actually supposed to feel the opposite: that we're expanding our knowledge. Over time I realized that if I (or anyone else) don't understand, I am pretty sure that I'm not the only one ("the king is naked"). In addition, people will not necessarily see you as "ignorant" but as a serious person who is not ashamed to ask to do a good job.
Not asking questions, in our context, makes our tests cover less and reduces our debug abilities, and bugs will always come out right in these areas (believe me, I know this from personal knowledge).
Today I can say that there are questions I ask that I know in advance that they will sound stupid, but I ask them anyway in order to ascertain one or another subject. Sometimes it is clear to everyone, sometimes it turns out that there is no consensus at all.
So my advice: If you don't understand something - ask. In case you are not sure of something and prefer not to ask, you can say something like: I want to be sure I understand correctly - ... and repeat what you understood.
Mind your language!
Technical terms
When you are presented with a new feature for example, and you have questions, the best way is to use the same terms of the presented subject, and generally accepted vocabulary. Otherwise, the person who is asked will need to "translate" your question to the terms he or she knows and might misunderstand.
For example, you may ask if the new feature uses a lot of communication, but better ask what is bandwidth needed. Or not if the program remembers the data but is the data stored or kept in the code?
Ask a question accurately
For example, this new feature is constantly working. what would it do to the phone?
Well, there are many things that can happen to the phone. The person that is asked might think of CPU and he will answer - not much. But you thought of the battery, and maybe if he knew the answer would be different.
But truly, asking questions is like planning the tests
Questions for understanding is one thing. But you also want to challenge the technical solution for the purpose of making it better. Sometimes one question combined both purposes.
I gathered a few questions (I am sure there are many more). You can use them as a cheat sheet in technical presentations, just be sure the question is relevant to the solution.
What will happen if this fails? ("this" - any point in the flow).
What will happen in case of network/hardware failure?
Will the data be saved in case of any failure?
Do you have error messages for the user?
Will I see all actions in a log?
Will this have any effect on other features?
How will this influence the platform (OS for example)?
CPU, Battery, I/O...How can I test this process?
How did the competitors solve this issue?
How will it handle interruptions?
Is there a race condition?
Do you lock the DB?
What will happen in case of process overload?
How long should this process run?
Does it support backward compatibility?
How many instances will run in parallel?
Does it have API?
How does it handle different time zones? Different languages?
...
Comments
Post a Comment