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.

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.

The Test Data Stopped Me from Committing a Blunder

Recently, I took up testing of a feature and it was one of the critical releases from a point of business. We had to create new systems technically and associate with the existing system for a flow to complete the business need.  This involved testing from at least 5 different endpoints other than different client endpoints.  But how to test it with the time I had? 

To test this effectively, I could have made use of existing data from the stage database and mapped it or dumped it to create a copy for the new system.  Then, I thought, let me create a fresh set of data.  The challenge for me in creating test data was:

1. I did not understand existing test data as it was not that straightforward and simple; most data were junk i.e. entered randomly, and created with automation aid to have some data, probably
2. It has to sample for 100000+ entries in production and its mappings to different fulfillment
3. It has to help in testing the newly built system in the unit wise and integrated system in each node wise
4. It has to help in figuring out the problems in each microservices and different client nodes
5. I had time of 2 days to prepare the test data
6. I had to understand the logic of how various associated microservices evaluates the same data for fulfilling the request
7. I had to understand how the data has to be constructed such that when it is fed to the cron job or scheduler, it will just pick it and insert them in the database and then associate the mappings
8. How to make sure this mapping is done right? How shall I test this mapping?
9. I will be getting almost 1 day to test this new feature on one client node after data creation.  How do I make sure the client endpoint is dealing it right along with other client nodes and microservices endpoints?
10. The products get shipped at the day end that is on the one day testing of a client node
11. What is the space I have to correct my error If I did in my testing now?
12. I was said not to test anything and just see if that functional flow is good enough to make one as usual fulfillment, to keep it simple one transaction in a business use case. Should I take this and just do this and nothing else?
13. I said to the team not to make junk data entry and call this as test data; I had stopped the team from entering data for two days in all interfaces
14. Data being created from automation in systems was posing challenges each minute during this time and I had to collaborate with different teams on the same while I had left with little time to complete my testing tasks and delivery from test team

I learn, my testing can be strong here if at all, only if I understand the data and how it gets fulfilled.  I decided to sit and create the test data.  While I created test data, I started referring to the production environment and created the data to simulate them.

I prepared 42 test data and I knew exactly what it is and I had sampled it enough to simulate 100000+ data.  I had taken close to 3 days for designing these data and associating it without the help of any cron job or scheduler.  I figured out how to evaluate these data in each node and microservice endpoints by this time.

This is the advantage of test data creation. I spent most of the testing time here i.e. in preparing the test data. It helped me very much!

With this, I had sets of tests that are "must" and any problem in these will be a blocker. In another set of tests, if there are any problems, then it can be called out by stakeholders if that has to be fixed or not for releasing the product.  I was left with 3 hours before they take a call of shipping the product, that day.  I had to cover my tests by this time.

It was about 2 hours left for the shipping decision, I noticed a behavior that seemed to be a release blocker. On informing it, I started looking at different client nodes to see if it existed there as well.  I could identify this blocker, because, I had designed the test data. If I had not designed the test data, it would have not been possible for me to identify it that day. One of the disasters probably in the product's and business history if this blocker bug had gone out as part of a release.  The functionality seems to work and fulfillment runs. But the feature is not doing what it has to do.  See how tricky it is - it functions but it does not do anything that it is supposed to do eventually. The disguise!

If I had just carried out the functional flow per communication I received from the engineering management, I would have done a blunder as a practicing tester. The business does not do this purposefully; they assume it will be handled and there is no need to test this.  If I have to make the same decision as a tester that is as engineering management and business, I should be convinced enough to say, there is no need to test this at this point in time given the context. I took it up by making time in available time to test each endpoint. 

The functionality flow seem to look good but the outcome was not what the business wants and it is not obvious anywhere in the GUI.  Debugging this behavior, I learned this is a problem. I figured out the root cause of it and shared it with the programmers.  I was given a new deployment to test for the same, later.  The shipment of the product did go on the same day. I wrote the RCA for the same on receiving a fix.

Why did I share this here?

1. Test data is an important part of a test
2. Time what we spend on creating tests and data, usually it is not seen as part of testing and not included in the time given for testing
3. Sampling and creating the test data is a skill to be improvised each day by the tester
4. When said don't test this, as a tester have enough confidence and rational analysis before not testing it; else, as a tester, we will be supporting the growth of the risks in product and risk for using the product
5. The creation of test data helps to know different endpoints of a technical system; if it did not help, then we are not preparing the right test data
6. Blockers, bugs, and ambiguity always exist; the tests and test data should help in making it simple to understand and know the root cause
7. If I had not worked on this test data, I would have not identified the blocker and it would not have been possible for me to test each end node of client and microservices

Now if the use cases are automated in this feature, the automation can assert for same on different end nodes because we know what is the data and what is expected out of it. There is no need for me now to do this as extensively as I did this time.  This is one of the benefits of automation which lets me focus on other stuff in testing.

Note:

• Never exaggerate the bug report saying technical investigation and root cause. Rather, we can provide, this is what we learn from our test investigation.
• Never exaggerate the test data and underestimate the test data. Anything associated with test data is worth investing time to look at it and know it better.

CI & CD - Exist to solve the engineering problems for first than to solve for customers

I read a tweet post of Michael Bolton. What made me to share my opinion as a blog post is, I hear CI and CD associated with Software Testing quite often; especially in the software testing conferences.

Here is what Michael Bolton asks on Twitter:

Your CI/CD system is probably pretty good at helping you discover problems in the build process. How does it support the discovery of problems in the product that would matter to customer, the team, or the business? Note - there CAN be really good answers to this. #DevOps #testing

The CI and CD is not associated just with Software Testing, but it is integral part of Software Engineering and Development.  In 2006, I have seen CI and CD. In 2017, I see CI and CD. The change is, how we are building software today, when compared to 10 years ago.  The CI and CD has taken upper hand for how we architecture, design and work in building software, before putting it to release line for market.

I want to say this -- "We seeing or associating CI and CD with testing is okay but it is not all about the testing. It is about the engineering and testing is one part of engineering." I see this emphasis is missed in the conferences when they quote CI and CD and tag a word testing with it, especially with automation context.  Note that, when I use word "automation" here, it is not the automation part of testing deliveries, it is the automation part of the engineering pipelines as well.  Yes, the *pipelines* of technology and engineering stack.

We have multiple pipelines in the engineering and from different engineering teams which may span over different geo locations and work culture.  With this, I say, for first CI and CD has to deliver and serve the engineering teams and also the teams which work with engineering team, before serving the market customer or business. If it is not serving here, then that CI and CD has a fundamental problem that needs to be addressed.

Before thinking of Testing as a focusable space in engineering and shippable product to customer, the testing can be seen in strong form and it is "Unit Testing" while product is being developed. Plus the integration of different pipelines outcome while the Unit Testing is executed or being executed or about to be executed, as the code get pushed. This summation of different pipelines integration constitutes a picture of product which gets shipped to customer, one day very soon.  Note that, this product is not yet available to customer in market, while it may be available to different stakeholders within the engineering team and teams associated to it. We need it to vision our work, vision our product and vision my testing for the product.

The CI and CD do not remove any problems nor add problems.  If not handled CI and CD, the problem can get disguised and may ship to market.  For example, did you see a force update of software you use?  The CI and CD, waits and look forward the human's push so it can do its job and give back to Build Engineer or any other engineer.

Testers, do not get panicked about how the word CI and CD is used with Software Testing and automation. The CI and CD is beyond this and it starts with the integration of different engineering technology stack pipelines outcome as one output and the unit tests.  

I don't know how true is this, I heard from my friends years back that Amazon builds for every 11 seconds. Could be and I'm not surprised with it. You see the CI and CD here? The compiled build or deployment does not mean, shipped.  It is the gateway for unit test run and integration of different pipelines.

The coverage and testability offered by CI and CD can vary based on how it is used. It is just like this -- if you noticed a tailor marking the textile to stitch a shirt; the measure of the marking again; cut it on the marks; tie it and give a number; the other tailor picks it and thread it; then pass it to other tailor to add and do necessary stuff before it is put to shirt hanger or cover for handing it to showroom or customer.  What the tailors did it here is the CI and CD. In large manufacturing, these tailors can sit in different places and can work in different time.  Where is the testing here? You answer it! How this CI and CD of tailors help customer to wear a comfortable shirt? You answer it!

Now, just think how many of these tests are technical tests facing tailoring skills and those tests which are facing the customer in the market on having a wearable shirt.

For the teams within engineering, when we have practices that benefits engineering to build better product, then CI and CD is of help.  Because with such engineering practices, the problems in integration of product and building it, can be identified earlier.  This can be identified if we have such Unit Tests written or built; else, it won't.

The CI and CD does not mean no bugs; but helps in identifying sort of bug(s) earlier in the engineering cycle.  These tests are more towards the technology and tech stack facing than facing the customer in the market.  But that does not mean we cannot have tests for customer facing in CI & CD.  This customer facing tests comes when we have the build which can be used by different types of users, stakeholders and testers in business team.  Example of tech facing tests, a MVP (Model View Presenter) not having defined logic container/controller association to pass the information to the viewer; this can be figured out if there is one such unit tests upon integration.  This bug may not be visible in UI if the contract of client and server partially satisfies; it may be seen when looked below the UI while doing the customer facing tests.

For me, be it tech facing or customer facing, test is a test. When tests can reveal product information earlier, why not to tap on it, if that can be achieved using the capabilities of the CI & CD ?

Providing the build having technology facing tests to business teams or SMEs, may not get that powerful feedback always to engineering team in initial stages of development. I have witnessed such outcomes when said about UI is not right, alignment is not right, keep it bold, keep it in lower font size., etc.  Though these are useful feedback, when it is being received is the point here.

To end this post, the CI and CD is first to address the internal engineering problems and assist in having effective engineering, before solving problems to the customer or business.  CI & CD is C[I+D] before seeing a product and problems it can have.

When "Communication" is Overseen!

I got a call from one of my friend. I could see my friend being disturbed from last few weeks. I listened and did not share anything as I know that person is going through his times and let that be discharged.

All I asked was,

• What makes you feel it that way?
• How it makes you feel?
• It's completely okay to be in state what you are, not a concern at all. See how you can hold that in your hands and just say you are done with it and pick something else. Tell me how will you do that once you feel you are doing it.

Being a friend and a senior to my practitioner friends, I feel, it is my responsibility to be with them, when I strongly think I should be there and assist.  

Shockingly, I heard, that friend was asked to take salary cut quoting "you are bad at communication; to help you improve we are deducting your salary and pay 30.x % of your salary". Is this a communication of an organisation or a leadership team or staff?  

I feel, I have no rights to speak about the organisation or about those people in leadership team.  I asked my friend, "are you not happy with your salary cut?". My friend said, "salary cut is not a problem at all. But how they gave me hike saying you are a bright employee and your hard work deserves it; now after two months I'm said you are not doing good in communication though you are brilliant in work and we want to deduct your salary for this reason."

Further my friend said, "this is making me feel more hurt and I'm unable to sleep and can't focus on practice."  He was one of the practitioner, who practiced on self with no much help and solved the problems that came up while practicing.

See what a communication of an organisation has done to a bright and talented practitioner! Making a bright talented employee to go into depression state is one of worst communication of an organisation and leadership team, is what I feel. 

My point of writing here is assisting a friend and not the organisation or that leadership team.  If that organisation and leadership team did that, they will continue to do that each time in new versions. Something like the bug fixed is fixed in a way but it is dormant in many other ways which is unknown and it is experienced at one fine time. 

All I wish to request for who wants to build an organisation and who wants to get into management leadership team is, understand communication if you are trying to emphasise on communication. Lead by example and not by the words of English. Do not mistake English or words of English as communication. The words are not communication! English is not communication! The body language is not communication, it is one of the out come and assisting factors of communication.  I see people joining organisation because of leadership team and their vision and I have seen people moving out of an organisation because of leadership team and communication of them.

Listen to your friends who practices along with you! It is mark of a team work and do best what you can. If the best is just listening patiently, do it and help your practitioner friend to discharge that emotions. The discharge time of emotions varies person to person, and all they need is that personal touch and feel of they are valued and listened.  That said, one should know how to pull it out collaboratively and emphatically.  I believe in it today, and I practice it.  I just don't assist technically but I do assist with personal touch.  My people are one of my strength when we want to accomplish the goal and set a new one!

The organisation is a HOPE.  The leadership team is the wings of the HOPE. The employees are the body to which the wings are binded.  The journey all together is the vision and mission of an organisation i.e. enabling the HOPE.

If something is not right with wings or hope or body, there is something fundamentally wrong which has to be fixed, before addressing anything else.

Problem Not From SDK; But, I Said, That's the problem. I'm Wrong!

Today's software is not like the software and hardware what I saw in 2006 to 2010.  I see the software which we are building today, it integrates third party software vendor's SDKs.  As well, today's software what we are building are not desktop application like in the 2000s; but the applications on the desktop and mobile which can connect everywhere else and serving the user.

Recently, I was testing a product which is in its initial state of MVP. It integrates four SDKs from different software vendors.  Among these, one SDK showed a behaviour which was unusual and the engineering team which I was part of, raised the request for support from that SDK's vendor.  While the behaviour what I observed in the product was uncertain and over a period of week, it took a stable behaviour.  When asked, I was said it is due to SDK.

Here is the miss, what I did for first. I took those words as I had got used to this behaviour for two weeks with no technical solution. I did not question enough that and debug around as the time what I had for testing was also crunched. I and other fellow tester owned the ownership of testing for the release. Stretching late nights and weekends, it all drove me to take words when said it is technical limitations and nothing can be done.  Here is the second miss what I made -- I took these words as the behaviour due to SDK and previous experience was consistent and synching very well.

The story got different in production.  One of the user reported the same behaviour and I was confident in my reply and said, it is as a known behaviour.  My other programmer friends had same opinion.  My programmer friends here are highly skilled and they know their job very well.  But we all were fooled by the software as the pressure which eventually starting building upon us. That was also due to the experience of us talking with that SDKs team.

I took up that behaviour for investigation again today after hearing from production and from a techie friend who said, "it should not happen for so long".  Yes, it should not happen for so long as I expect it should be gone after the synch is done, is what I think as well.

I started questioning myself and doubting what I have learned.  Isolated all the environments for my observations and started watching my actions, the requests, the responses, the pay load, the race conditions, the served and unserved data streams, the logs, and the breakpoints & values in code eventually as I did all these moves. 

I was wrong! Yes, I was wrong in what I said confidently to every stakeholders right form CEO, CTO to all other business stakeholders. Also the engineering team had the opinion what I had.  It was time to go back and tell them, "I'm wrong in what I communicated in behaviour of the client software and rational behind it".

I gave the reason why it happens, when it will happen, when it will not happen, the impact of the behaviour, work around for same in production, is it dependent on anything else and awaiting, and why it was a missed from our end technically.  It was not a problem from third party's SDK. It was a UI that got triggered each time when the activity got triggered. 

Though I have to investigate much lot for other problems in using that SDK, this behaviour is not due that SDK. It did work well in this case here.

What I want to say here?

• No matter how confident in the code and in tests, we will be fooled and are fooled each time
• There is no harm in doubting ourselves for second time on -- what we have listened; what we have ignored; what we have learned; what we have not carried technically while we observe the behaviour from the tests consistently
• Being non-technical in our observations and work helps a lot
• Knowing the benefits of not thinking technically each time
• Giving time to ourself so we sit back and investigate the behaviour which everyone claims it is due "that"

• If it is due to that, you will happen to learn about it so you can test it better
• If it is not due to that, then you will happen to learn it is not so and can figure out the cause of it; help team in fixing it

In this case I see no impact to user in terms of data and performance of product, but the experience is definitely annoyed.

So I learn again, that I should build the tests technically -- which will put the product into test for the experience of each feature; each UI; each actions of user on a UI; each interactions with backend and its outcome to the client; and evaluate the outcome of the same.

How will I do this? I can do this sitting in person and also with help of automation.  But the point is what is the scale where I have to be with my tests samplings to experience it and investigate further. This takes time to learn and it won't happen in crunch time of releases.  Having said this, it is not bad to go and talk with stakeholders and buy the time quoting the priority and impact of the behaviour. We testers will have to initiate and assist the stakeholders in learning when there is a need for it.

PID Cat - Reading the logs and test investigating the Android apps

Reading the logs and helping self to design better tests is one of the key skill for a tester, is my opinion.  I insist and encourage the testers to practice it. I assist in learning the log and making use of it.  If you are not sure whether the product you are testing has a log or not, it is time to know it.

It can be server logs, proxy logs, client logs, hardware logs, deployment logs, etc.  The log contents and type of logs will vary from product to product.  What goes into log will also vary and it depends on what is the log level set to print into log file.

It happens that the logging will be turned off or will be set to minimal saying it consumes the disk space and IO of the box where it exists. On the other hands, the DevOps and programmers usually monitor the logs in production.  The logs are one of the most useful utility to know whats happening in the production.  While they use it in production environment, can't we testers use the same in the staging and pre-production environments? Won't that help us to test better? Yes, it will help!

Understanding how the logging feature is written for the product is one of the key task usually missed by a practicing tester. The way of interpreting the observations and further test design will be influenced upon learning how to use the logs.  

In this post, I will share one tool which helps in context of testing the Android mobile apps. The logs and Android devices; if you say, "logcat", yes; it helps to print the logs in different logging levels. What if I want to pick for particular Android app from the debug stream of logcat log? It is not an easy task with logcat's output stream. 

I have been using the PID Cat for years now and I find it very useful. It is written by @JakeWharton  in Python.  It prints the logs in colored text and we have choice to change the color and choose what we want on our box in the program written. Upon that I can just fetch log for a particular Android application.  Also, we can contribute further to this tool. The readability experience of log on using the PID Cat, is better.  Read about the logcat color script from Jeff Sharkey, it is here.

How to get PID Cat?

On Mac OS X, the PID Cat can be installed via brew.  If brew is not configured on the Mac OS, configure it. On successful configuration of brew, using the below command the pidcat can be configured.

brew install pidcat

On Ubuntu, the PID Cat be installed by using below commands in terminal

sudo apt-get update

sudo apt-get install pidcat

On Windows, install the Python and configure the path. I have tested it with Python 2.7 and 3.x during my tests. It appears to work for me in my test environment.  

Below are the steps to use PID Cat on Windows machine.

1. Install Python and configure the path
2. Make sure the path of Python is set
3. Make sure the ADB is installed and the Path is configured for it
4. PID Cat is a Python program and it is available in above mentioned Git repository
5. Get this Python program file and save it locally on the drive
6. Go the drive where the pidcat.py is saved and enter the command in terminal -- python pidcat.py com.package.name
7. This should start printing the logs and on Windows 10 OS, I see colored log text

If using the Cygwin on Windows OS, install the Python package and make sure it is installed. Now go to root and access the directory 'cygdrive'.  From here choose the physical partition drive of Windows OS where the pidcat.py file is stored. Then use the below command to fetch log of specific app.

python pidcat.py com.package.name

Note that, for all the above said, the ADB has to be configured and set in path. If not, it will create trouble. The general log of Android device can also be collected via PID Cat, by using command -- python pidcat.py .

Android device logs in colored text in Windows OS via Cygwin

Android device logs in colored text in Windows OS terminal

Now having setup the PID Cat, while it is up and running, let us test and debug the apps much better.

Web Client Performance: Webpage's Response Time and HTTP Requests -- Part 1

I'm practicing along with my colleague Chidambara, on Web Client Performance Testing (WCPT). While we practice together, we are learning, how to assess the current capability of the web page and then how to interpret the same.  Why I say this, because when I test, I will make a report; that test report as to help one to decide and assist in taking the necessary action if it has to be taken. If not, the purpose of the test report might just bound to know what did I test and what is my interpretation. For this, I need not write the test report.  The same with automation as well, isn't it? We will get the report on running the test suite and this report will be used further to decide what to do based on our interpretation of it. Coming back to WCPT, I happened to learn it this way and sharing my learning with my fellow tester.

I picked a Google India search page and monitored its requests and response. At time of testing, I used Firefox in private mode. I noticed total of 16 requests were fired and close to 1.4 MB data were transferred. Overall it took 4.62 seconds on 100 Mbps bandwidth internet line. Below picture reads the requests fired and its timeline.

HTTP requests fired from Google Search India page

I notice, first two redirection taking total of 294 ms, and then 484 ms to load the html document. In total, to load the html document, 778 ms is used. This is close to a second. If I had to make it to round figure, say 1 second to load the html document. Without html document, the web page will not get loaded and for this reason html document will be the first content to get downloaded on client i..e on the browser.  Notice that there are two redirects with HTTP status code 302.

I will walk through in a blog post how the redirects affects the web client performance potentially. I and Chidambara, practiced the same few days back.

Moving ahead, I see other 3 seconds are used to download the images, stylesheet (CSS) and scripts. This tells, more time is taken to download these elements of the page then the html document. When looked into other web's webpages the same is observed during time of testing.  With that, I learn, these elements are the time consumers if not handled well thereby showing the slow response time. Slower the response time is, i.e. the more time is taken to load the functional webpage.

Now you see, while carrying out the functional test you also test partially for the performance of it, and vice versa.

The 'capability' i.e. performance attribute of the webpage will be -- "how quickly it loaded on the client i.e. what is its response time".

Note that, the expectation is, it should be functional and  the experience of using it should be pleasant to the user; these are the implicit expectations with the words 'capability' and 'response time'.

In above picture, the total time for receiving the html document is 778 ms. But, the event DOMContentLoaded is fired after 1 second and somewhere it looks near to the mark of 1.2 second. Where did the 442 ms go then? On my network bandwidth of 100 Mbps and machine configuration with 8 GB RAM, still this is a question to me. Then what will be in other network bandwidth and client's machine configuration? Why DOM parsing took time?

I see there is JS being received i.e. in 8th request. I'm not sure if is synchronous or asynchronous. Technically where there is no dependencies between the scripts or any other page elements, keeping it as asynchronous helps.

Then there is a CSS being received in last second request. If the CSS isn't received well before, then page loading has to wait for it as the style cannot be defined for the parsed DOM of loaded html document.  It is a thumb rule to keep CSS in the top requests while receiving from the server. But context of the website's design can change this thumb rule.

If this gets tested, can the response time of the Google India search page can come close to 3.3 to 3.5 seconds?

If this is just for one webpage of a website, how many webpages do the product I'm testing, have? Now I understand very much better than ever that, like functionality is coded into the product, the performance as well should be designed and coded in equal importance.  I derive my tests with such thought process as it serves me to be the base in building the tests and for sampling the variation and interpretation of test observations.

What did I learn here?

These are key learning when I happened to interpret the Web Client's performance

• More the number of HTTP requests, the response time increases for the webpage
• Lesser the number of HTTP requests, it is good from point view of webpage's response time and performance
• The html document takes minimal share in the total load time of the web page and rest of the time is taken by the webpage's element
• Handling and optimizing this is important for better performance of web client
• More the page weight, more the response time for webpage
• Need to test and figure out is there any way the page weight can be optimized, so the response time for webpage will be fast
• If said, 15% of time is for html document of the webpage and then other 85% is for the webpage's element, then the problem area is evident with respect to response time
• If fine tuned the client for better performance, the experience for targeted user should still be pleasing with better response time
• Upon this, if server performance is optimized, then do targeted user say, "it is just like this, so fast"? I do not know; but as a practicing tester I see, fine tuning the performance of web client is possible for a tester while she or he tests the website for functionality or any other quality criteria. In parallel, if taken care of server performance based on contextual learning from the tests observation, it will be very much useful.
• Know this when looked at webpage
• Number of HTTP requests fired; 
• time taken by each requests; 
• what each requests carries from client and back from server to client; 
• size of the HTTP request transaction; 
• page weight and contribution by each elements in the webpage; 
• know when did DOMContentLoad event got fired in the timeline;
• in above picture it is marked with blue line in the timeline
• it is fired when the html document is completely parsed and loaded without waiting for other elements of the webpage i.e. css, js, images etc.
• know when did Load event got fired in the timeline;
• in above picture it is marked with red line in the timeline
• it is fired when the page elements are loaded and finished loading
• overall response time for the webpage;
• understand what each page element is and why it is needed;
• it is very much important from aspect of testing to know is it actually needed for the webpage or website
• if it is not needed, then as a tester I should be in position to advocate my observations out of tests
• if it is needed, then as a tester I should be in position to advocate my observations out of tests and how it can be tuned and optimized

It is important to know what is HTTP and how the web communicates. So that we understand the influence of bandwidth and latency on the response time. In next post, I will share what I have understood for the same. Later in subsequent will share, how I and Chidambara progressed in learning and practicing of this.

My Learning from Agile Testing Alliance's 12th Bengaluru Meetup

I attended Agile Testing Alliance's 12th Bengaluru Meetup hosted at Moolya Software Testing Pvt. Ltd., office on 25th March 2017. I got to know about this meetup from the Facebook share by Moolya and made my mind to be there. The audience in the meetup were software testers, Agile trainer or coach, and technical lead.

Below listed presentation came in time between 9:40 am IST to 12:50 pm IST

• Welcome and introduction to Agile Testing Alliance, by Nishi Grover Garg
• Challenges of Agile for a Manger, by Preeth Pandalay, Techno Agilist, Agile Coach & Trainer
• Behavior Driven Development: What, Why & How - from a tester's perspective, by Vinay Krishna, Agile Technology Coach
• Problem Solving Techniques: An attempt to apply ideas across disciplines, by Ajay Balamurugadas, Tyto Software
• Creating 100 mindmaps in 1 minute, a demo by, Dharamalingam K, Moolya Software Testing Pvt. Ltd
• Concluding the meetup and vote of thanks, by Nishi Grover Garag

Brief lines on presentations from my notes

I'm listing few points here out of my notes. It was engaging sessions and I had to make sure that I will listen, I make notes and tweet to people if any who were curious to know what's happening in the meetup.

Nishi Grover Garg : Introduction to ATA and welcome note

• She introduced herself and shared about the Agile Testing Alliance and what it does
• Said about the recent testing conference that was held i.e. GTR Pune 2017
• Shared about the different certifications and the assistance from ATA

Preeth Pandalay : Challenges of Agile for a Manager

• Started with management structure, management hierarchy and bureaucracy
• Spoke about management in 21st century and in technology era
• Shared his views on traditional structure of management and Agile management structure
• From there, he spoke about traditional manager and Agile manager
• Mentioned about the network based management and said it as organization structure 2.0
• Then he said about Agile Team Cross Functional and mentioned Katrina Clokie's blog which speaks about this
• With that he said, Agile team is self organized
• He shared statistics of Agile helping to solve and deliver better
• With the statistics walk through, he says, Agile works
• Audience had question around -- "Management yet to getting adapted to Agile and teams are on Agile. How to solve this so team gets much more support?"

Vinay Krishna : BDD -- What, Why, How - a tester's perspective

• Started by asking do you know what is BDD and then said it is another buzz word and jargon
• Says, "in this era we all are programmers and need to write code; testing is a specialization now."
• He said about the surprises that software development brings and highlighted on "assumptions" what people make in team
• Started a group activity saying to draw start having 12 points and later he asked "why you did not ask questions but assumed?"
• Says, bug + feature = beature
• misunderstanding at all levels
• lack of effective communication
• difficulty in communication
• lots of assumptions
• Then he shared, BDD = shared understanding by discussing examples
• Continuing his talk, he said, for start have at least three amigos -- Business Analyst, Programmer and Tester
• Also says, it is useful if identified and used more than three amigos
• Shared about how important a scenario and use of Gherkins
• Mentioned on BDD framework saying,
• Feature File
• Step defintion (glue code) 
• Actual implementation
• Started another group activity and asked to identify the scenarios for a ATM transaction
• He said to avoid UI tests with BDD
• Shared few myths around BDD
• BDD is automation of functional testing
• Using Cucumber is BDD
• BDD is replacement of functional testing
• Took questions from audience around
• Difference between unit testing and BDD
• Around usefulness on BDD
• Deriving the benefits of BDD in performance and security testing
• Limitations of BDD

Ajay Balamurugadas : Problem Solving Techniques: An attempt to apply ideas across disciplines

• Starts by asking, "How do you solve problem? Take a minute and let me know."
• Audience started interacting
• There were no slide and it was a white board and interactive session througout
• Then he mentioned about a crisp definition for "what is problem?" of Jerry Weinberg
• difference between expectation and reality
• He mentioned about Problem Solving Leadership workshop by Jerry Weinberg
• He says, "focus on things which can be controlled"
• From here, he asked the audience to pick any one problem, so that he demonstrates how to solve it
• The audience picked -- why less number of attendees to the meetup
• He started to brainstorm around this problem while audience interactively shared their thoughts on how to solve it
• Nishi Grover Garg, said this is useful and it will be used from the next upcoming meetup
• Moving from here, he said about four techniques which can be used in solving the problem
1. Attributes and Improvement
• by, Robert P Crawford
• Further with examples he said
• identify the problem and list out the attributes of the problem
• work on the improvement of the problem
• If you miss out an imporant attribute, problem might not be solved
2. Six Thinking Hats
• by, Edwared de Bono
• Mentioned about 6 different thinking hats -- White, Black, Yellow, Green, Blue and Red
• Briefed what each hats means and what they signify
• He recommended to avoid using Black hat immediately after the use of Green hat
3. Questioning
• He said the importance of questioning
• Mentioned about Osborn Questioning
4. SCAMPER
• A mnemonic
• S - substitute
• C - combine
• A - adapt
• M - magnify
• P - put
• E - eliminate
• R - rearrange, reverse
• Later he shared one more mnemonic which he made while on the way to meetup
• PROBLEM
• P - perception
• R - reasoning
• O - opportunity
• B - beware of assumptions & problems caused by solving the problems
• L - lawfulness
• E - exploratory
• M - management
• He took the questions from audience on the techniques and applying it

Dharamalingam K : Creating 100 mindmaps in 1 minute, a demo

• Walked through swiftly on what is Mindmap and where it can be used
• He shared about the problem what he and his team encountered when wanting to build a mindmap for a product's feature
• Then, he said how he built the mindmap via Python program
• He ran a quick demo which showed creation of mindmaps
• He took the questions from audience
• On mindmap
• On the complexity and how to do this via programming

Nishi Grover Garg : Concluding the meetup and vote of thanks

• She thanked the audience who made for the meetup
• Said about the Agile Testing Alliance and benefits the people can get from ceritification

I took below to my desk from this meetup

• How to handle myself in teams which claims to run on Agile
• How to coordinate and deliver my best in the environment which claims to run on Agile
• How to focus on my work irrespective of Agile or not Agile and assist fellow testers and stakeholders
• Thoughts and questions around BDD apart from functional testing
• A mind which says to explore on this
• To focus on things which is in my control and where I can deliver
• Do not take responsibility without having the authority
• I repeated this to myself again
• To read and build skills from below resources shared by Ajay
• Attributes and Improve, by Robert P Crawford
• Game Storming, by Dave Gray, Sunni Brown, James Macanufo
• To explore and use what I can to learn in the web -- http://humansystemsinaction.com

Post meetup hours, was part of three interactive discussing sessions with Ajay and Pranav. I did learn discussing to Ajay and Pranav on fundamental topics of software testing, programming and practice.


Here is a pic from the meetup

Attendees of Agile Testing Alliance's 12th Bengaluru Meetup hosted at Moolya