Agile Archives -

Transforming Software Testing: A Journey from Basics to Specialized Excellence

Charting the Course: A New Paradigm in QA

The software landscape is ever-evolving, and in its flow, the role of Quality Assurance (QA) has burgeoned from a mere checkpoint to a strategic cornerstone. It’s a narrative of transformation, where roles within software testing are no longer confined to generic titles but are sculpted into specialized beacons of expertise.

The Genesis: More Than Just Testing

The inception of our journey was marked by a recognition that our QA team, a mosaic of potential, was marooned on an island of outdated structures. This epiphany was our call to action – a call to sculpt a robust career pathway for every tester.

The Blueprint: Values that Mold Careers

We leaned on our core tenets of curiosity, creativity, and collaboration to lay the foundation for roles that would not just exist but thrive. These values were not mere words; they were the crucibles that shaped the roles we envisaged.

The Spectrum: From Junior Pioneers to Architectural Maestros

We delineated our career paths into clear strata, each reflecting a distinct echelon of expertise:

Entry-Level Pioneers: Where the journey begins, our QA Interns and Testers are the bedrock, honing their skills, learning the ropes, and imbibing the essence of quality.
The Intermediate Vanguard: QA Engineers, the intermediaries, who with a balanced blend of skill and innovation, take on more intricate aspects of testing, curating quality with each test case.
The Senior Strategists: Senior QA Engineers, the specialized craftsmen, wielding tools of automation and analytics, architecting the frameworks that uphold our standards.
Leadership and Visionaries: QA Leads and Managers, the navigators of our QA odyssey, charting the course, steering through complexities, and anchoring the team to its goals.
The Specialized Elite: Performance and Security Experts, the guardians of our software’s integrity, ensuring each product can withstand the tides of demand and the shadows of cyberspace.

The Revelation: Roles That Resonate

Each role now resonates with a defined purpose, echoing our values and encapsulating the skills and responsibilities pertinent to that stage of growth. This clear delineation has not only catalyzed professional growth but has also enhanced the quality of our products.

The Vanguard: SMEs as Beacons of Mastery

Subject Matter Experts (SMEs) in Test Analysis, Performance, and Security have emerged as the vanguards of their domains. These roles are not just titles but are sanctuaries of expertise, each SME a beacon guiding their peers towards excellence.

The Odyssey: A Cultural Metamorphosis

The rollout of these roles was not just a structural change; it was a cultural metamorphosis. A once rigid hierarchy gave way to a dynamic ecosystem where each role is a stepping stone to a zenith of specialized prowess.

The Harvest: A Resounding Triumph

This transformation has been a resounding triumph, with our QA team not just meeting but redefining industry benchmarks. The clarity in career progression has unfurled potential into performance, and ambition into achievement.

The Continuum: A Pledge to Perpetual Evolution

Our journey doesn’t plateau here. We pledge to perpetually evolve, iterating on our structures and roles, ensuring our team is not just current but cutting-edge, not just testers but trailblazers.

An Invitation: Let’s Converse and Collaborate

Are you on a similar voyage? Are you considering charting such waters? I am eager to share insights, and strategies, and perhaps, learn from your narratives too. Let’s collaborate to elevate QA beyond its traditional bastions, nurturing careers that transcend expectations.

Why we went Agile in First Place

Why we haven’t been properly Agile even though we do Scrum, Kanban, SAFe or any other framework at team or organizational level

After another gap, I am finally able to write. It has been a strange period on the personal, country, and then worlds’ level.

When they started talking about going Agile and championing the benefits of it, on a beautiful resort in 2001. They although coming from having different principals, frameworks, experiences, and concepts. They agreed on something.

The agreement is well known, we call it the Agile Manifesto. They put forward some commonality and one of the most important aspects that were agreed upon was “Responding to change over following a plan”.

What we understood and have been actively preaching are

Must follow a framework
It only applies to Team

Usually, that framework is always either Scrum or Kanban or something in between. Sometimes we are so hell-bent on following the framework we lose focus on the bigger picture. We say okay framework says this but you are not following it so you are not Agile even ignoring the fact that person or team is delivering great outcome (value to client) and responding to all kinds of changes efficiently and being market-leader.

Then going to the next step, when we talk about scaling it up, we again get stuck in trying to find a scalability framework. Altogether ignoring the cultural, organizational, people, functional and other aspects. In a 2018 publication “Agile at Scale” of “Harvard Business Review” talks about the same thing.

So, what now?

While searching for answers, I came across a concept “Disciplined Agile”. I admit I am still learning the ropes of it and will only be able to go deep once I have a proper handle on it. But on the surface, it feels more organic, natural, and less restrictive.

Disciplined agile encourages you to focus on Mindset. It encourages you to establish your own way of working, which it calls “WOW”, and to help you on the path instead of rules and regulations it shares with you guidelines that can help keep on track on the journey. It talks about experimenting, empathy towards customers, finding why we started what we started in first place, talk about leveraging all the assets on your disposal and having a system in place to help grow not become the system.

But having all said and done, there must be a framework that DA follows? Shouldn’t it be? As that is always the catch, BE AGILE they say and then They give you SCRUM or KANBAN, or LESS, or NEXUS, or Scrum at Scale.

GOOD NEWS!!!!

No DA does not want you to be FRAMEWORK driven. It champions the following mantra

“True business agility comes from freedom, not frameworks. Disciplined Agile helps you learn about your options and guides you to your best next step.”
Project Management Institute

What DA does instead if provide you with a Toolkit. That tool kit has 4 important layers, Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise.

Rights to this IMAGE are reserved by Project Management Institute , its used here for education purposes only.

I will talk more about DA Toolkit in next blog.

I encourage you all to explore this, as having the freedom to deliver the best value to your client in your own way should be the actual Agility. Doesn’t it make sense after all?

Important Announcement: if you are facing any issue regarding Agility, Agile Adaption in your team or organization, Test Management, project management, and/or Application Life-cycle Management, please contact at askabk@abkhalid.com. For Test & Project Management Consultancy, please reach out at abkhalid@gmail.com.

Agile Conference 2018

Recently I attended Agile Conference 2018, in Islamabad as speaker. This was very well organized event by Pakistan Agile Development Society.

I will share detailed experience later on. For now, I am sharing copy of my slides that I had the opportunity to present in regard to selection of Agile Methodology to ones’ cultural and organizational needs.

AgileConference18_Presentation

If you have any question or want any help on this, please reach out at abkhalid@gmail.com

Its “Us vs Them” Mentality

Its been couple of years, that I have had the opportunity to write & share something. I hope I am not that rusty!

It was early 2010s when we started hearing and discussing about Agile in larger audience. Especially in Pakistan. Initially people thought, it’s a ploy to remove testing resources altogether, as there is slump in markets and companies can’t afford to have “freeloaders”.

I remember, having multiple discussions with my friends and telling them, relax man, we are here to stay. But deep down, I had an itch, what is this “new way of development” where no testing, or documentation is required.

Let’s back up a little bit. In traditional software development lifecycles, there was always a Testing Face, and the biggest question was QA v QC or Verification v Validation. But we knew whatever the distribution, but we will have our time for each project, where we will be working on the application/software as per our own understanding of the requirements. We (some of us thought) were too good in business side of things, so we only knew what client wanted and devs where there to only put blocks together).

By having, ”our time” (in other words testing time or cycles) there was a clear divide, it was Testing vs development.

It was then, and presumably with more common understanding / knowledge of Agile Methodologies, with mantra being one team, one would assume that this would have gone. But no, it hasn’t we still keep fighting the battles, we still have battle lines drawn.

I have been scratching my head and trying to find out the root cause. And up till today morning, I was thinking we need more coaching for our team members. But something clicked, and that is, we the dinosaurs need to change first. We still keep fighting the “Us v Them” battles. Even though our resources have been put in same teams, but we the “Managers” are still holding the rope tight. We still keep on believing that they are our resources. We keep on encouraging “our” resources only. In reviews we try to find faults with resource from “other” team. Try to hide the issues of one’s own resources.

But we must realize, as soon as you step in to world of Agile, the resource managers are not managers, they are parents, that have to let their children decide their own path, and to quote a windows phrase “Sit Back and Relax”. Let them make mistakes and learn from them. Help them if asked, don’t go running to find the issues. The more you let them be on their own the more they will learn.

So agile coaches, please sit together and sort us out. Make sure we believe in one team concept, rather than preach only.

I have done my Manager (Traditional Manager) to Manager (Agile Coach) Journey, have you? More on this in my next blog.

Important Announcement: if you are facing any issue regarding Agile Testing, Testing Organizational changes, HP’s products for Application Life-cycle Management, Functional or Regression Testing and/or Performance Testing, please contact at abkhalid@gmail.com , I will try my best to help you out.

You can also share your opinion and if any particular topic you want me to cover I would love to do it up to best of my knowledge.

Test Management and Snow Ball effect of “Agile Development”

Most of us have been exposed to project that never follows actual project plan; the changes can be new features, new add-ons, defect fixes or new integrations. For every test manager these projects take a snow-ball effect, that is they keep on growing along the way, and you are never sure what to expect from them. And to make the mater worse more rapid the changes or defect fix, lesser the duration between the builds. But the area to test keeps on increasing. Another factor to consider is the trend of software development companies to “fall” in to Agile Development, where they “think” everything must be parallel.

Now what it do to test managers is very scary, you cannot get the automation kick in, as application is being updated regularly, you cannot add more resources, as “You don’t need more resources, you already have got it tested”, while if they do not get it all tested, you get to hear, “Mr. what are you doing, look there is very important bug your team missed”.

To tackle all this I have made my policy that for a project that is behaving like this (let’s say every new build is within less than two weeks of other) I usually deploy two resources; both resources do test new features for first week. For next week depending upon the available time, needs to change test cases, I on daily basis try to cast a net on areas that are near to new features, where one resource test the application, and other update the test data and test cases for next build.

And for last couple of days before the next build, we do a strategic exploration of application, which is for every build we select one or two modules and do exploration for the application.

This is not the ultimate test management process, but honestly since the advent so called agile development, and lack of cohesion between builds and marketing team’s insistence of new build every other day; this is the best I could devise in 5 years of my test management.