In designations provided in all companies, in the last few years, did you ever notice the fact that there’s no longer a “junior” prefix to any designation anymore?  This month onwards, I am going to call myself “senior” Fake Tester; I am going to give myself a promotion and feel happy about it. Do you know why? It’s the same reason as to why a software engineer is promoted to a “senior” software engineer, or a test lead is promoted to a “senior” test lead. And a “senior” title is always associated with many promotions? Did that “senior” tag actually make you feel better at all? Anyways, what’s in a “senior” anyways ….?

Last week, we were working on “search” functionality; some bugs that I raised were not fixed. My colleague, “copy-pasting” developer asked for a reference to the requirement document for a specific functionality. I said if you really want to look at the requirements document for such issues and he said “Yes”. “Delspe” went around blaming the “business development” writer for the lack of a requirement document, and those folks in-turn went and blamed the client; finally they convinced the client to pay more money. If the company had spent the same amount of “engineering time” in solving the problem, as the time spent on the “blame game”, these bugs would have gotten fixed well in advance. More of that another day. All of these started me thinking on where the requirements come from.

Actually, before going forward, I’d like to define 2 types of requirements; 1 is the features which will be seen by the end-user or by the customer; 2nd is the set of features which would be a part of most of the protocols and help with interacting between 2 sub-systems. I agree that the 2nd set of protocols will need a reference document “call it requirements” to test and confirm if all the parameters are being met. But let’s come to the 1st part and talk about requirements. As a tester, I think it’s very important to understand on what’s the right reference point for requirements and to understand where do requirements come from?

1) The customer’s mind – His Perception – As a customer, I have some perceptions about how features should work; and requirements would need to be derived from there. For example, I would like to search for a book “The three mistakes of my life” as “The 3 mistakes of my life”. It is not practical to expect the requirements document to contain a requirement reference that says “have a reference to the value 3”, if the title of the book contains a number. It is very important for the development and QA teams to understand this kind of customer perception while talking about requirements and come to a logical conclusion, instead of indulging in an open warfare to understand if it’s a bug or not.

2) The local law of the land – The law of the land where the systems would be hosted is something that most of us forget about; understanding the legal rights of customers is very important for the tester. A simple example is that if there is going to be a customer site hosted in a location, and if the law of the land states that the site should support the visually handicapped, then the support for that should be built into the systems.

Another example is, if I’d like to change my name from “Fake Software tester” to “!@#$$^”, many systems cannot take those values; it is my fundamental right to change my name to !@#$$^ and I don’t think any system would accept those as input values. So be very careful when you file that bug for an invalid “first name” or “last name”;

3) Requirements of competitor products – As a customer, if I have been using the flipkart systems, if a new company called “zambago” come up with a portal similar to flipkart, I’d expect the same feature of “flipkart” search in “zambago” search too; for example, I’d like only 10 reviews loaded in “search results” and have more loaded as I’d scroll down the pages. I’d also expect the client to be available in all browser, android systems that flipkart is available on.
Secondly, always do keep a constant look out on newer features that are deployed by competitors after you freeze your requirements; the customer expectations would be that these features also need to be available in your products.

4) Other platforms that support your application – let’s say that you work for testing an “email system” feature; let’s assume that your client is available on multiple applications. Now, if you are building a new client, the expectation is that every feature works the same across various applications. So it is very important for you to reach out to your other supporting teams, understand how other client systems work and ensure that your client also works in the same way.

5) Customer Feedback forums – it is highly likely that there are a lot of online forums on which your customers pose their thoughts and queries; keep constantly monitoring and watching this space to understand customer requirements.

6) Meeting notes from your client/customer representatives – there would be a department in your company who represent the customer; and there are going to be multiple meeting notes if you plan to have a new feature, understand the small print in meeting notes from these. It is highly likely that this is how they want a feature to be and we are missing the bus.

And last but not least,

7) The actual requirement document itself – And in the middle of all of the above, let us not forget the “requirements document” itself; this document would contain a lot of content that is very important and serves as a point of reference to the engineering teams.

Why the requirements document too? It is an important document that helps the engineering teams to understand requirements; but there are a lot of dimensions not covered by the requirements document and more often than not, these dimensions are completely ignored.  On multiple occasions, the end-product becomes a result of “What we can deliver” rather than “What the customer wants”.  Apart from the requirements document itself, I’ve listed some dimensions above from my personal experience that I feel that the engineering teams need to look at to understand what the customer wants; what the requirements document mostly is that they document only a sub-set of “What the Customer Wants”, provide only a few references to how systems should work and mostly do not reflect how the actual customer behavior should be like.

 

Fake Software TesterA Fake Tester's DiaryFake Tester,Fake Tester's DiaryIn designations provided in all companies, in the last few years, did you ever notice the fact that there's no longer a 'junior' prefix to any designation anymore?  This month onwards, I am going to call myself 'senior' Fake Tester; I am going to give myself a promotion and...