alikhalid

For engineers technical skills are vital,

Unfortunately so are people skills, because ultimately we have to deal with humans.

And you’ll find every kind of them in a work environment.

Problems occur when an individual or organization neglects any one of these skills

Less technical skills will lead to weaker products with lots of issues,

Inadequate people skills will also lead to weaker products with lots of issues..

Because products are not built by one person, a group of ‘teams’ build them.

And successful teams have people who are good technical and inter-personal skills

And this will drive product quality.

#RedefiningSoftwareQuality #QualityTransformation

The word automation “framework” is sometimes used incorrectly.

Would you classify Selenium, RestAssured etc. as framework?

IMHO these are libraries, using which we develop frameworks.

Frameworks are built using a number of libraries like the ones mentioned.

There might be some common utilities of your own, some additional reporting you’d add along with a reporting library etc.

In general, a ‘framework’ IMHO will be something you build for your product using a number of libraries.

Linked article for further details:

Have you faced problems like not having enough time to test, or automation not being prioritized?

That means you don’t have your Definition of Done set right..

A story should be considered ‘Done’ only if the ‘Definition of Done’ has been completed.

Enough time to do exploratory tests & automating the important scenarios (Unit, API & UI) should be part of your definition of done.

If these activities are not taken up as part of delivery, then your accumulating technical debt

As your tech debt grows, so will your problems with delivery & quality.

And after some time, your product will be in a heap of mess with everyone scratching their heads about how to fix it.

#RedefiningSoftwareQuality #TestAutomation #Testing #Agile #DefinitionOfDone

Hiring automation engineers has always been a trick thing.

And the worst thing you can do is to add all the buzz words you know of around automation.

Finally when the candidate comes on board they end up doing exploratory testing only!

Here are few pointers for hiring:

• Look for programming aptitude.
  • If your framework is in java, not necessary to hire someone with 10 years of Java experience
• Testing acumen.
  • Are good in identifying risks
• • While a can-do attitude is a must, for automation positions someone who ‘enjoys’ problem solving is required

More pointers in the linked article below

#RedefiningSoftwareQuality #TestAutomation #Automation #Hiring

Have you felt writing and maintaining test case documents a drag?

Because they are…

The old school thinking was, dev write code, testers write test cases

I talk about:

• Why the traditional way of doing test case management is inefficient
• What is a better approach?
• How will this save more time

#RedefiningSoftwareQuality #QualityTransformation #Testing #TestCaseWriting

I’ve noticed few common mistakes teams make in their transformation journey:

1. Very detailed long-term planning.

• They have a target state in mind, and then start planning in detail every step of the way.
• Processes, procedures, day to day activities planned in detail
• That is the trap agile was supposed to free us from, we’ve learned we “can’t” plan long term accurately,
• So, don’t design intricate plans

2. No long-term plan.

• Then you have teams who believe they are ‘truly’ agile and believe in not thinking more than 2 weeks ahead
• “If you don’t know where your going, chances are you may never get there”
• That too is very problematic, you’ll stay in fire fight mode if that’s the approach

So, what’s the middle ground?

1. A) Have a long-term vision.

• Crystalize the vision so everyone knows where we want to go.
• That does not mean over documentation, it means start ‘living it’, should reflect from your actions

1. B) Plan few weeks

• Do have an approach to how to get there, but make it very short-term and to the point
• That’s because it will change, you’ll try learn and then try something new
• Your plan to get there must ‘evolve’ along the way
• PDCA – Plan Do Check Act

#RedefiningSoftwareQuality #Transformation #Agile

Releasing quickly and with less toil / effort allows you to:

1. Get feedback from customers quickly

2. Improves your product quality

3. Helps you earn more money, fast..

To start on this ‘cultural’ change, include all the right things in your DoD – Definition of Done.

And this should be the effect:

The ultimate KPIs for software development?

Here are the top 3 I feel are important:

1. Defects from production – Severity and quantity.
– This should be the end goal that should matter.
– Most of the other quality KPIs like automation coverage % etc. are not the end goal,
– They are how good you are following ‘a process’, which may or may not achieve in the ultimate goal.

2. Mean bug identification time
– Average time taken to report bugs after code commit.
– This does not mean just JIRA tickets raised as bugs, automation results showing failures giving feedback too are included.
– This will capture how quickly we are giving feedback on code changes, which is a significant part of driving costs down.

3. Release cadence
– How quickly do we release a feature, starting from conceptualization till deployment into production.
– This should include all the lead time across all processes.
– The company that masters to speed this process will win, since they can adapt and change quickly looking at how customers respond.

There can be many other KPIs, I personally want to care about only these 3.

#RedefiningSoftwreQuality #DevOps #KPI #Automation

Some wisdom I learned about being an effective communicator:

Speak in such a way that others love to listen to you.

And

Listen in such a way that others love to speak to you.

Learning to speak is relatively easy. Learning to listen well is harder, and is more important.

In case your wondering, vital skill for improving your product quality..

#RedefiningSoftwareQuality #Communication #Collaboration

Assessing skills of individuals is required. Be it academics, interviews, courses / certifications and so on.

IMHO most assessments are not optimally designed which creates a lot of problems…

My biggest issue: assessments are designed not based on what is practically done on a day to day basis, instead on theoretical, trick questions which are far from practical application.

Most of the time, that’s because perhaps these theory-based ones are easy to design and ensure you’ve ‘read’ the text.

I don’t endorse this even for academics, but in interviews especially I think these are just nonsense.

Judge the person on what practical value they will bring, or value they have delivered before.

Oh, BTW, I add test like ‘codility’ in this category too (when was the last time you needed to solve O(N Log N) for work???)