Thursday, December 14, 2017

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.



Wednesday, August 23, 2017

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.