0

Data table loading all data at client side and then doing pagination. I marked this as an issue as the table could have more data in future.

But Developer is not convinced and says it's best to load all data at client side. There is not any specification. But I believe we should only fetch the amount of data which is required for a moment.

How can I convince him its bug?

  • 2
    Hi Palak, what's your question? – trashpanda Jun 7 '18 at 7:26
  • How can I convince him its bug? – palak Jun 7 '18 at 10:26
  • What do the requirements say? – trashpanda Jun 7 '18 at 10:29
  • There is not any specification. But I believe we should only fetch the amount of data which is required for a moment. – palak Jun 7 '18 at 10:39
  • How does it impact user for large amount of data? Have you measured response time for that? – dzieciou Jun 7 '18 at 12:22
2

The developers shouldn't be convinced if it's a bug or not. If you think something is not working as it should but you don't have any specification about how the flow should have been, you can do the following:

  • add a comment to the task about the issue you found
  • open a new task with the modification But always talk to a project manager/business analyst/product owner who has the business knowledge and can decide about the workflow.

What I recommend is not to "force" bug reports. The aim is to have a good application which works as expected, not to annoy the developers. But always be aware:

  • the product owner knows about the behavior
  • your observation were written in an email or task tracking system
  • your observation reached the desired people

Note: I recommend you to read the ISTQB Foundation Level book, even to take the exam. It's not a big deal at all, and at some point your experience will overtake that book with miles, but it's a great book to clarify the roles and tester approaches.

0

What impacts user experience in the most degree (when you load up "all the data") is the data processing speed. When you load the data from server, it is stored on your client (no matter whether you show only "a page" of that data) and then is somehow processed. Normally it is processed by JavaScript that is executed withing the execution environment that is embedded in a particular browser.

Here I can see several issues.

  • The data consumes memory. This might become critical on low-end machines taking into account that the modern browsers take huge amount of memory even not being loaded with any code
  • Depending on what the browsers is (its vendor or version) it might differs how effectively JavaScript is interpreted and hence what CPU consumption would be when you process such a large amount of data

So I would take the following actions to convince a developer this is a defect (architectural defect):

  • Set up some proxy (sniffer) that would let me fake the server response
  • When browser requests the table I would fake the response iteratively increasing the amount of data returned (for all the supported browsers). This will take some amount of time.
  • For each such iteration I would perform some user UI interaction which the users are expected to perform normally (not requesting the server) such as data filtering, page switchiong, sorting, etc.
  • For each such iteration I would measure the time taken for processing the action.
  • Then I would build up a chart showing the dynamic of time depending on the data volume.

enter image description here

Having this dynamic chart you can come to your developer and show that say if the data will increase twice as much as some reference amount, the UI response time will increase by 5 seconds which will obviously impact user experience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.