Friday, August 2, 2019

Challenges in Building the Skilled Software Testing Team and Testing Leadership



In testers meet, I was asked, "I happen to see overlooking the value of building the testing team and contributions team make to shipment. Do you see same in your work? How to solve it?"


Before I went ahead to discuss on this, I had silent in me.  I see certain problems are in the culture and mindset for first.  Bringing a change here is not that easy - culture and mindset. It also applies to testing teams. It also holds good to any others (or teams) interacting with the testing team.

Taking the analogy of skilled carpentry work (say, "pepperfry") - we will see how this exists not just in testing but anywhere. But in testing, it is not changing after decades too. That's the problem causing unbearable costs and not the actual problem. It's not being attempted to understand by who needs the testing, in my opinion for today.

A skilled and experienced carpenter can do her/his work quickly and with values, right? How many carpenters exist today who can do job at least to level of saying this is the minimal must value and job, I need without the supervision and initial assistance from skilled carpenters.  If seen, the assistance in carpentry work is not for weeks or months.  It takes longer time depending on the skills, mindset, passion and attitude of person learning the carpentry.  Now comes the context - there is a list of orders coming in; the skilled carpenter has people who started carpentry and the people who can do job on consistent supervision for 'x' period of time. If the skilled carpenter puts her/his time in doing the work day in-out to deliver the orders alone, may be orders delivery will be met but with diminished values in work eventually? How long the skilled carpenter can do this i.e. all alone? The skilled carpenter should not assist her/his fellow carpenters and help herself/himself or people who will be hiring them for job?  I learn, the skilled carpenter will assist and give her/his more time in closely watching her/his fellow carpenters while chipping out the core part of the orders.  What if the fellow carpenters quit and join elsewhere? That cannot be stopped by any means. Due to people quitting does one has to lower the standards of one's work? Do the furniture brands say we lower our standards of product as we find carpenters quitting the job? NO!

Relate the same to Software Testing and Automation.  Including me, we have people in software testing -- who knows jargons; who knows how to use what they know in shallow or not know at all; and starters. Here we will have serious people who are interested and also not interested.  Considering the current time (future as well hopefully) of people or team who needs the testing team, isn't that a skilled tester job to build a team on which they can sustain and rely in coming days?

This long activity i.e. building of testing team can take years. And in my experience when had a people with right attitude, consistent efforts and passion - it can take close to 2 to 2.5 years for one.  In these 2 to 2.5 years, we can see people tackling the testing problems if practiced well. But people do change job in 2 years or so, now should I invest in it?  This is one of the invest-cost-value problems which has made Software Testing to take back seat.

It has gone to least priority when considering of having the skilled testers and testing team. Because, practicing testing is not done by most. Later saying this is testing to people boarding the team/org do this and getting the lower returns and values for team & org. Eventually blame the testing and testers. One simple example, we are aware of Design Patterns in programming and know several books/authors who has authored.  Do we know the Test Designs and design techniques apart from black box, white box, grey box, and any books or authors who have authored on same? Blinking of brain starts here!  I feel there is no need of better example than this.

Everyone has experience but that does not mean they are practitioners.  This is the trouble with people boarding into practice of testing. They happen to hear and work upon hearing - just do this, like this, this much, and as this. Write your test cases, automate all, bug reports and everything here. If that can be said in ease, it can be done in much more ease. Why hiring of the testers and having testing team?  Now you know the trouble and pain points of building the testing team and testers?

The expectation from the skilled (carpenter) tester is X+1, but the people who gave the job/orders see it is y-X and not far close to X.  This is the exact case with people or team hiring the testers and wanting to see the "proportional" value right away in the product and to the organization.  It can be achieved, if considered just the skilled (carpenter) tester and for a shorter period of time. But is that the expectation of people who pay for the all carpenters (testers) doing the job in a business?

To see the value of a test, it can happen in a release or few releases. To see the value of testing being done or not done, it can take few releases.  To see the value of having the skilled testing and their work, on which people rely, it will take years.  I see same applies to programming team as well. But in programming space we have people who practices it and then assist boarding people.

In the testing space, we don't have practicing people to assist the boarding people and existing people, in the right way.  This contributes to laggard and continue giving a low mark to the testing team and testers.

Now is it -- problem of the industry; problem of the org; problem of the people or teams wanting to have testing teams; problem of the testers itself?  Whatever, the impacted entities are -- industry, people or team who want to have skilled team and of course testers too.  Help the testers, testing teams and testing practices you have in your org. By this, you are investing. When investing know if it is done in a right way and on right stuffs. Otherwise, the investment made today in testing can become blocker cost.

If a skilled (carpenter) tester is working on building the future carpenters by giving her/his assistance, it is not a simple job! That's the bigger value. Doesn’t the business find returns one day out of this assistance? I say it is not simple job.

The skilled (tester) carpenter knows that he/she is not doing in full what she/he has to do in a given context while continuing to assist other carpenter.  But negotiate in open mind with stakeholders by bringing the understandable and mutually agreeing communication - what is expected immediately out of carpentry work given or the orders that came in.  If this is done, half-the-problem is solved when you have skilled testers.  Often, this will not happen and skilled tester too fail here. 

The communication of expectation for a carpentry work coming from different people; to whom should the carpenter look upon and deliver the asked delivering the work?  We testers and testing team have this problem as well in getting our work set and delivered.

How to solve?
1.   It needs a leadership in testing at org and in teams.  The test leadership, if they are testing practitioners it is good and boon. But hands-on practitioners might find time constraint to be in management and hands-on delivery. Yet this is do-able in my experience.
2.      Testers need to pull up themselves and bring the change in-out.
3.     Culture and mindset problem, needs better way of solving and not the software testing way i.e. how software testing solves problems.  Unless having the faith in software testing and how it solves the problem, it cannot be used as a relativity in learning to learn and solve the problems.
4.   At the bottom, skilled practitioners will be on the hit list most times. Unavoidable! But that should not put down the Software Testing community and practitioners growing. One day you will be recognized, remembered and highly valued for what you have done.  Just make sure you don’t incur big costs personally by doing this activity. Balancing is the key here and it comes only by incurring the costs while doing this activity

If not bothered about
·        need to transform into skilled testing practitioners;
·        org not having/wanting the efficient testing teams;
·    continuing the shallow and low returns testing & automation, which is highly accepted, paid better for doing that and you don’t care a penny anymore about it,
then do not attempt solving this problem for you, your team, and your org. It will never be solved. It will just increase the troubles to all.  One day it will be realized and it will be picked to solve by stakeholders upon having the costs.


Note: I admire how the "pepperfry" crafts its furniture. I wonder why the same cannot be achieved by carpenters who do carpentry while constructing the house. I'm left with many thoughts on this and I try in discussing them with a tester in me.


Tuesday, December 18, 2018

Understanding Web Services, APIs and Architectural Pattern



Since I started my career in testing, I hear and see these words frequently -- 'Web Services', 'APIs', 'Service Oriented Architecture', and 'SaaS'. In recent seven years, I heard word 'Microservices' quite frequently. 

In overall, when I talk to practicing testers, we hear this question during discussion in knowing the differences and understanding of same.  I too had this confusion and questions.  I worked upon it to know them and trying my best to understand what they mean. Today I test them and continue to update myself while I learn what they mean in its existence and purpose.  

In this post, I share what I understand for them by saying the differences I have figured out.  So that, it helps other testers or SDETs.


Web Services


Before getting into word 'Web Services', I want to understand what the word 'web' and 'services' mean. The word 'web' - interconnected systems over network. Then what do word 'services' mean in this context? I learn - services is the endpoint of a connection; it has computer systems to support the connections that it offers.  Then Web Services is - the technologies that allow for making the connections over web and its protocols. Thereby we connect the services together using Web Services.

The Web Services are offered by making use of:

  • SOAP (Simple Object Access Protocol);
  • REST (REpresentational State Transfer it is a representation style of architecture, and not a protocol );
  • and, other web technologies which includes protocol and architecture pattern


Service Oriented Architecture (SOA)


SOA is collection of services, where services communicate with each other.  It can exchange data from simple to complex form between one or more services to accomplish a purpose of activity (i.e. request).  Now we see that service - i.e. a function to be well thought, defined,  and not to depend on state and context of other services.  The service will have consumer (consumer of service by requesting for it) and provider (provider of service as response to request).  Note that service provider also can be a consumer based on contexts.

With this I understand, SOA is a software architecture pattern. The service provider provides the service to consumer over communication protocol.

Note: Few protocols which are commonly used - HTTP and SOAP.  I remember the days where I tested CORBA based services.



Application Program Interface (API)


Thinking in this perspective, I believe, it helps understanding it better -- information hiding. The 'hiding' here means, independent modules which can communicate with each other and exchange the only information which is required. Thereby accomplishing the modularity with independent modules.

This enables for the creation of interface which can be used by other software systems (i.e. service consumers) to access the data and update if required. 

The APIs usually will be implemented using Web Services with help of SOAP,  HTTP, REST and other protocols and architectural representational styles.  When said REST APIs, it means the APIs adhering to the standards of REST.



Microservices


It is an architectural style which structures the application as a collection of services. That means, an application can have multiple services which are -- independently deployable; not coupled to other services very tightly; which can be tested easily in isolation to other services; easily maintainable by a programmer; and it represents the business components i.e. business's services.

For example, the search in https://amazon.in, is one service; and, the order fulfilment is another service. Either of these service is being down does not affect other service in its functional operation. This is one benefit of microservices architectural style. 



Pictorial Representation




In the above pic,

  • how two end points (service consumer & service provider) communicates is with the help of Web Services. Web Services is a concept how two end communicates in a view.
  • Underlying system and data it processes, is not visible to service consumer. The service consumer just sees an interface i.e. API through which the specific service's request is made and it gets the specific response. The API does not expose other functional behaviour of underlying system and data it processes.
  • The way these services are structured and organized forms architectural pattern of the system. It can be any architectural pattern and few commonly heard are -- SOA, Microservices.
  • How consumer talks to interface (API) changes quite often and not the interface. Likewise, how the service has to be provided by service provider changes than the API i.e. interface.


Relating a daily life example


Air ticket enquiry and booking system:
  • Airline and consumer are two end points. They can communicate to each other via phone call, email, chat, or in person.  There is a protocol which defines how this communication to happen between the two end points.  A service is provided to a consumer.  In tech, relate this to Web Services.
  • Different protocols for different communication types i.e. I can't communicate as I do in email when I talk to airline staff in airport.  Relate this to SOAP or REST, to start.
  • To enquiry about my customer membership with airline, I need to talk right person. A front desk staff might not be able to provide this service.  Relate this to API i.e. specific service request and an interface to it.  I don't see how they the info to me; all I see is the details of my membership and share it with me.
  • If the check-in system of the airline is not functional, still the ticketing system of that airline can be used to buy a ticket. This is an example of microservices assuming 'check-in' and the 'ticketing system' are two microservices which are not dependent on each other, though they interact to complete the business need.
  • Having distinguished services and staff assisting for it in airport, so that consumer can go and consume what is needed, will sum up to Service Oriented Architecture style.