HTTP2 Migration Tests to consider on AWS's ALB

 

Is your team planning to implement HTTP2 and have services hosted on AWS using ALB?  Then you might have to consider the below tests on priority for start

By default, ALB sends requests to targets using HTTP/1.1.  Refer to the Request Version and Protocol Version at https://amzn.to/3uPaxl1for sending the requests to target using HTTP/2 or gRPC.

Here are few tests to consider on priority:

1. Do all my client interfaces have migrated to HTTP2?
• If not, having ALB on HTTP2 and few clients on HTTP/1.1 will make ALB use HTTP/1.1
2. What time it takes to respond if I'm on HTTP2?
3. What is the traffic pattern i.e. how the frames (frequency & size) delivered to the endpoint on HTT2?
4. What happens to the client if there is a delay in response?
• If serving users who have low bandwidth or intermittent networks, what should be the product experience to them?
• What if you are queuing the requests and it is by the design in the system?
5. What's happening at the endpoint?
• What happens when there is a POST and PUT from the client as multi-part and not as multi-part?
• When a bunch of requests is fired at once what's the size of each batch and frame in it?
• Does the client still adhere to the HTTP/1.1 style of dealing with requests and response, or upgraded to deal the HTTP2 way?
• How the timeout is handled on the server & responded to the client it handles?
6. Do the libraries I use at the client and server end support HTTP2?

Bug Report: Applying the Single Responsibility Principle (SRP) and KISS

 

On completing my test sessions, I started to write bug reports into the tracker. I had this thought coming up again in me: "Should I keep all these problems under one bug report or have a separate one for each?".

• When we have the test with SRP (Single Responsibility Principle) and KISS (Keep it Simple and Straight), why not the bug reports?
• What's wrong if each symptom (consequence problems due to the root problem) has an individual bug report but linked to the root problem report?  

At times, I'm said to include all symptoms in one bug report along with the root cause.

• I have witnessed the symptoms of a bug do not get fixed if it is mentioned collectively in one bug report.
• Also, the linked bug reports (i.e. symptoms of the root cause) do not get fixed when the root is fixed. It will be marked as Resolved and Fixed as the root is fixed and resolved.

Hardly I have seen the symptoms as well fixed along with the root cause.

That leaves with the questions:

1. Just one bug report or separate bug reports?
2. When a test has to be specific with individual responsibility and objective, why not the bug report?
3. If the root cause is fixed does it resolve the symptoms?
• And, if the symptoms are resolved does it also resolve the root cause?

I look up to my consciousness should it be the separate bug reports or just in one bug report.  I see, I can apply the SRP and KISS to the bug report effectively.

Looking at the number of bugs is not a wise strategy. But looking at the number of problems that one root problem opens and tracing them, is useful in the engineering of a product.