Wednesday, October 4, 2023

Performance Testing: Unspoken KPIs and The Missing Correlation

 

I love Performance Engineering!  In a nutshell, the performance is all about capability in a given capacity,  in a context.  The context is critical element in Test Engineering.  In the common language of a workplace context, the performance it is about the productivity expected and delivered.

This blog post is part of 100 Days of Skilled Testing series.  The first question posted for season 2 is,

What key performance metrics or KPIs (Key Performance Indicators) do you consider when defining performance requirements?  Do you use the same metrics for client and server-side performance testing?  If not, these differ in what way?


KPI Classification

On a high level, irrespective of a boundary and interface of a software system, the Performance KPIs can be classified into two:

  1. Service Oriented
    • It helps to learn by correlating,
      • How well a system is providing the service to the intended users in a given context?
      • How a system is not providing the service to the intended users in a given context?
      • For example, Response Time, Availability, etc.
  2. Efficiency Oriented 
    • It helps to learn by correlating,
      • How well an application uses its features and resources in a given context?
      • How an application is having trouble in making use of its features and resources in a given context?
      • For example, Utilization of Resources, Throughput with the resources available in the context, etc.


Performance Engineering & Metrics

You will be aware of the other commonly spoken or written metrics that a performance tool offers or has it in its glossary.  I want to focus on KPIs what we are not aware or not exposed to in the communication or Performance Engineering & Testing Report.

The metrics in Performance Engineering & Testing depends on what in the system, I'm putting to an evaluation.  

For example, we do not consider how a feature is implemented and how many threads it can spawn and use in a given point of time.  Further, this leads to CPU and its logical cores, RAM, Disk I/O, and types of server or machine used.  Also, another important data is how the OS is setup with configurations where the different tiers of a system is deployed or installed.  These metrics are common either when I'm facing a client end or serve end, yet it is missed.

If you notice, these are hardly spoken or heard metrics.  But it plays a crucial role.  A performance report compiled should have this data so that the technical people can correlate with other commonly heard metrics.

Being aware of the KPIs that are commonly seen in the Performance Report is a must.  But, knowing what we are not aware or/and missing besides the known is a necessity!  This is missing in the correlation when evaluating the performance's perspective of a system.


The Missing Correlation

Identify what in your report is a need to correlate.  The statistics or numbers are representation and not a derivation.  It is of no use until I derive out of it with a correlation.

I have to derive the correlation by including and also by eliminating the representations.  For doing so, the missing correlation representation is a must so that KPIs look rational, technical, logical and analytical.

Uncover what is being missed in your correlation so the KPIs representation look senseful!



Wednesday, August 16, 2023

When I Questioned My Learning -- What is Automation?



I'm questioning, revising, refining, and versioning to update my learning and practice with Automation in Software Testing & Engineering.  This blog post is about how do I define and understand the Automation and Software Testing.


Automatic and Ation

I started by breaking it into classes (words).  I see the better picture of what it does and what it means.

  • Automatic
    • which runs on its own with little human intervention where it is needed.  
  • Ation 
    • means an action
When put together, Automatic + Ation = Automation.

I do not want get into from which language did it come from.  I got what I need here.



Automation and Software Engineering


Today, the context, area, scope and subject of Software Engineering has grown when compared to last two decade.  This is a immense change, progress, and growth.  I can think of automation in each area of Software Engineering, today.

I will stick on to context of programming the code, testing of this code, and what to automate by learning how and why.  My work and practice is here for last one decade.

I unlearn and learn by redefining to myself:
Automation is the use of technology to execute a task with reduced human efforts.


I said, reduced human efforts and not elimination of human, and human efforts.
 



What is Software Testing?


It is a parallel engineering that is engineered in Software Engineering.  When said engineering, it is about civilization, learning the [actual] problem and solving the [priority] problem.

Then, Testing is about learning how well it is being engineered.  It is an exploration, study, execution, evaluation and connecting all these to know the differences if any with its value and cost.

Testing is part of Engineering without which  Engineering cannot exist.  Testing goes in parallel as an engineering to the engineering.

That said, Software Testing is an engineering that runs in parallel to Software Engineering.  To me, the definition of Dr. Cem Kaner for Software Testing looks to be closer as a engineering practice.  It says,
  • Software Testing is an
    • empirical
    • technical
    • investigation activity
    • carried out to provide quality related information
    • to stakeholders
    • so that they make informed decision

With the help of Software Testing, to an extent I will learn:
  • In what all ways the Software System appears to work - how, why & when
  • In what all ways the Software System fails - how, why & when
I will have a technical data that is rational and empirical to present my learning from the testing I do.



Automation in Software Testing


I'm learning consistently for over a decade now that automation in software testing is one of the ways to test and this has its own constraints and limitations.   It exists to assist the Software Testing & Engineering, and not to replace the Software Testing & Engineering.

When said automation, I use to think of Programming Language and executing a test via the code where the intent of the test is expressed.

But, today I learn, I can automate in multiple ways and in few context even without using any programming language.  Yet it is still an Automation in Software Testing.

I used a toy train to automate a use case of payment via card and NFC.  This worked very well in fact with actual card and POS equipment.

Most times, one equates Automation to the code.  It is not wrong!  But it does not have to be code of a programming language always, either. 

As I said, if Software Testing is an engineering, then, Automation in Software Testing is also an engineering.



What About You?


Did you redefine your understanding by unlearning?  Be it yes or no, I'm curious to listen you.  Let us catch up!