I was recently invited by Fabian Böck for a chat over on his Youtube channel where he frequently interviews people in tech on various topics of interest in the industry. My talk was focused on how to steer the direction of your tech career. We had a fantastic talk about how to pave learning avenues, set for yourself time to reflect, and how companies should be enabling their workforce. And most importantly, how to ‘Never Feel Stuck’ in where you are – even if you are happy or not and use continuous learning and self improvement to guide yourself to better places!
Here is a link to the video interview-
Fabian’s company Boeck and XOXO works on Tech Conventions x Matchmaking Marketplace x Tech Talks. Check them out for more interesting talks and content!
“Debt” is not a pleasant term. It brings to mind a burden and generates a feeling of anxiety. The same may also be true for technical debt, or the extra work that we incur while developing our software in the form of missed quality targets, pending tasks, or skipped points from our exit criteria checklists. Like monetary debt, technical debt happens when we make a decision that is quicker in the short term but will hurt us in the long term.
Though we may try our best to limit this debt, it will still happen. And while we will need to pay back the debt one day, we can also use it as a lesson to help improve ourselves and our processes. If it ultimately helps our development, it doesn’t even always have to be a bad thing.
Though the first time incurring technical debt due to an inability to complete an activity as planned may not be pleasant, it should consequently improve the team’s estimation and planning.
Let’s say we had defined developers’ tasks for all user stories with estimated hours, along with a mandate of peer reviews being performed for all code being written. But the end of the sprint saw that though the developers marked their development tasks as done, none of the code had been peer reviewed before check-in. It could have happened due to lack of time or ownership.
The next sprint, the team then decides to have a separate sub-task for peer reviews under the development tasks, each of which is assigned to a peer with an allotted time of 30 minutes. This helps the team plan, have clarity around what tasks are pending, and see how much effort is being spent on the tasks.
So, even though you may begin to accumulate technical debt early on in your sprints, understanding the cause and having a plan of action may improve the team’s overall performance.
Sequencing and Prioritizing
If you find yourself at a point where release is a couple of sprints away and you have a number of unresolved defects, even though they are lower severity, the team may decide to reduce open defect counts for a sprint rather than adding new features. The technical debt incurred in the form of defects can urge the team to refocus and shift priorities.
Or, let’s say your team agreed to 70% automation of regression testing in the beginning of the release cycle, but after four sprints, the scripts they created are showing signs of being unmaintainable or not scalable enough. This may affect delivery in the end, so some testers may take the call of focusing full time on reworking the scripts and adding new automated tests to them, while the other testers take up functional and regression tasks.
My team once found out at the end of our fifth sprint that our developers had not been performing static analysis of their code or creating the reports that were mandated for every sprint. Whatever may have been the reason, this meant that running those reports now was leading to hundreds of errors or warnings all pertaining to code formatting, naming conventions and comments. Even though these were minor issues, it required time to get them all corrected with thousands of lines of code.
Getting test automation done is a challenge, especially within the tight deadlines imposed by Scrum. As much as the thought of continuous in-sprint test automation sounds enticing, the practicality of it may elude most Scrum teams.
In my article published here– I look at some of the main things you need to consider in order to get your test automation done within the confines of your sprint.
Framework
The first thing to focus on is a framework that is useful, is easy to understand, and helps all stakeholders participate in test automation.
This is essential because you want to make test automation a continuous activity that is a part of daily work, not a once-a-sprint (or once-a-release) work item. For this to happen, the framework must make it equally comfortable for a businessperson, developer, functional tester or automation expert to add their contribution and see the results of their efforts.
There are many business-friendly frameworks and techniques, like behavior-driven development (BDD), as well as many tools that can create tests in a domain language and then translate them to script code.
All stakeholders must be trained on using the framework, and their area of contribution must be made clear to them, with practical hand-holding. The automation tester can then focus on maintaining the framework, generating test suites and editing failing scripts, while the creation of test automation will be a continuous task assigned to everyone involved.
Collaboration
The next thing to focus on is collaboration between the various stakeholders. A continuous automation framework can only survive when it is being fed and tended to by everyone on the team.
The business people, like a business analyst or a product owner, can help by adding user scenarios or defining the requirements in a framework-friendly format. This may require them to be trained on the preferred format based on the framework being used
The developers can help by creating reusable methods for steps of the script. They can also create and maintain an object repository for all elements they add to the UI while testers use the pseudo names of the elements in the test scripts. This means that the scripts can be created before (and independent of) the application UI, and such scripts won’t need editing when the UI changes, as long as the object repository is kept up to date
The testers can help by adding more scenarios, specifying and creating test data, and executing the scripts periodically
Strategy
How to strategize the development of test scripts is crucial to making in-sprint automation a reality. Using API-level automation whenever possible will reduce the time and effort.
Many organizations take up the transition from waterfall to agile with the best intentions in mind. Like so many other companies, you might also be seeking to replace your traditional waterfall processes with agile in a quest to shorten the time-to-market and deliver high quality applications.
The road to agile, though, can be a rocky one! That’s why, in my latest refresh post for Ranorex blog, I have put together a few lessons and tips that will help you in succeeding in moving from waterfall to agile successfully!
I was invited to take a MasterClass by the wonderful people at the Ministry of Testing last month. They had a ‘Communities’ theme going on for the month of June 2021 and they loved my talk idea about Leveraging Tech Communities. So we worked around that theme to create a talk on “Grow your Career with Tech Communities”
Last year was hard in more ways than one. Amidst the pandemic, lockdowns, and changing global political climate, we are still forced into a survival mode of sorts. While many people struggle to hold on to their jobs, others are having a hard time adjusting to working from home while managing kids, home life and distractions. As we are cooped up with all the chaos around us, our career and growth plans might have taken a back seat for a while there.
We are now pacing through 2021. As we pass the half year mark in 2021, let’s take back charge of our careers and drive them in the direction we want!
In my article published here earlier this year, I discuss six tips to get your career as a tester back on track, or even take it down some new paths!
Learn a new skill
Learning anything new, whether it’s a new language, a new recipe, or a life skill like swimming or cooking, can help open your mind and create excitement for learning other professional skills, too.
Learning a new skill has always been the first tip you get to advance your career, and that’s because it stands true now more than ever. It’s often necessary in order to upgrade yourself if you want to land a new job or a better role. But amidst all the chaos around us, our minds might not be the best focused on learning right now.
Whether you were impacted by the coronavirus pandemic and lost your job, or your plans for a job switch were impacted or delayed, do continue to spend time and effort on learning something new that you have always wanted to master.
Diversify your skills
Testing is a multi-faceted role, and testers need to possess multiple skills to be effective in their teams. Especially in the ever-changing landscape of DevOps and agile, being a tester requires skills ranging from test automation to API testing to functional testing to security, performance, and load testing. We also need to be familiar with build processes, automated deployment tools, and white box tests.
Still, whatever your current specialty, you can always acquire another skill to better your profile and expand your skillset. Here are some ideas:
Mind map showing diverse skill sets a tester can acquire
Choose an area to specialize in
While it is important to know a little bit of everything, that might not satiate your hunger for knowledge! As you diversify your skillset, you are bound to recognize that you love a certain topic more, so you can then focus on specializing in that area.
As you dig deeper into that area of testing, you will learn more about the tools it requires, the best technologies to use, their comparisons, in-depth features, etc. This will help you participate more in discussions, showcase your advanced skill set, and eventually be seen as a go-to person for that job.
Test automation is imperative for the fast-paced agile projects of today. Testers need to continuously plan, design and execute automated tests to ensure the quality of the software. But the most important task is to decide what to automate first.
In my article published at the Gurock Blog website, I have have compiled a list of questions to help you prioritize what you should automate next and guide your test automation strategy.
Think of this like a checklist that helps you make automation decisions quickly and effectively and create a standard process around them for your team to follow. Here are the list of questions to ask yourself.
Do check out the complete article for a detailed discussion on each of these-
Is the test going to be repeated?
Is it a high-priority feature?
Do you need to run the test with multiple datasets or paths?
Is it a Regression or Smoke Test?
Does this automation lie within the feasibility of your chosen test automation tool?
Is the area of your app that this is testing prone to change?
Is it a Random Negative Test?
Can these tests be executed in parallel, or only in sequential order?
Are you doing it only for the reports?
Test automation tools will provide you with useful insights into the quality of the software that you can showcase with the use of some insightful reports. But are these reports the only reason you are looking at automation? Just looking at the red or green status results of the test reports might not be the best way to assess the software quality. You will need to spend time analyzing the tests that failed, why they failed, and what needs to be corrected. Tests created once will need maintenance and continuous monitoring to keep them up to date. All of that needs to be kept in mind and the effort needs to be accounted for.
There is more to test automation than just the fancy reports!
Looking at the questions above, analyse the state of your test case, the intent behind its automation, and its feasibility, as well as the value that you might get out of it. Hope that helps you decide what tests you should or should not be picking for automation!
Non-contact center applications of the Low Effort concept-
Customer Effort in Retail
Most critical factors when it comes to customer effort in retail environment are
“Navigability” – How easy it is for customers to find what they are looking for
“Issue Resolution” – How easy it is for customers to get help solving some problem.
Customer Effort in Product Design
Simplicity of design and ease of use really make certain products stand out in a crowd.
Apple’s ease of use is legendary.
Bose is another consumer electronics company that just ‘gets’ the idea of low effort. They put simple color-coded tags on wires that match the color of the jacks they plug into. Easy stuff!
TurboTax uses intuitive, plain-English, question based approach to helping taxpayers do their taxes.
Customer Effort in Purchase Experience
Decision Simplicity – Simplifying a consumer’s purchase decision
comes down to 3 things-
Making it easy for consumers to navigate information about the brand
Providing information that is noteworthy
Making it simple for consumers to weight their options
Effort should be reduced throughout the customer life-cycle.
Reducing effort in pre- and post-sales customer touch-points has measurable loyalty impact.
***
The Best companies Live low-effort.
Top brands are adopting the principle of a low-effort experience across multiple facets of their business, from product design to the sales experience.
I had the amazing opportunity to speak at the amazing event that was the WomenTech Global Conference 2021 #WTGC2021. This was a huge event for women in tech, minorities and allies from all over the world
The best part of the event was the interactive platform featuring live ceremonies, keynotes, engaging panels, breakout rooms, country & chapter leader sessions, technical workshops, and networking with face-to-face sessions.
I presented a talk on 8th June, the second day of the conference which was themed as “Inspiration Day”
Realising the power of Tech Communities in professionals’ lives
Learning to participate, volunteer and contribute to Tech Communities
Learning how Tech Communities help Products take their brand forward
How can companies build such powerful user communities and leverage their power
I was glad my session had many listeners from all over the world who not only participated along with their comments in the chat, but also left some amazing feedback!
Me speaking at the WomenTech Global Conference – virtual event
Not only this, I was also chosen to moderate 2 very interesting Break-room discussions that were based on impromptu questions asked and voted by all participants. In these discussions, we were able to have informal open discussions, ask questions and share our personal experiences on the chosen topic.
I was able to participate in the week long event and hear many amazing speakers talk about a variety of topics relevant to the industry.
Through this event I was able to connect to many amazing people from all over the world and so many amazing women trying to make a positive impact in the world of tech! I hope to stay connected with this wonderful community for years to come.
A special thanks to Anna Radulovski who reached out to me on Linkedin and invited me to speak at this grand event. She conducted the event with so much passion and grace and kept the energy going throughout the week!
Proud to be a part of an amazing set of speakers!
*************************
Here is the link to a recording of my talk- You will need to create an account to access
Reducing customer effort represents a cultural shift in how your team engages with customers and how you’ll prioritise the projects you undertake. But while it’s easy to say, any shift of this nature is difficult to accomplish, mainly because change in a large organisation can be an arduous undertaking.
Taking First Steps
Have a compelling ‘change story’ to communicate Why the change is needed, and make the business case of change. It then becomes the backbone of all communication, training, coaching and general reinforcement.
The most Important Change Agents
Focusing efforts on Coaching instead of Training.
Coaching is —
Focusing on improving future performance
Ongoing
Equally driven by coach and coachee
Tailored to individual’s development needs
Two types of Coaching tends to occur-
a) Scheduled coaching – sit-down discussions with supervisor to review calls, discuss performance and take corrective action. This might be more punitive than developmental. Over-emphasizing on this type of coaching leads to lower-performing teams.
b) Integrated Coaching – On-the-job coaching, in close proximity to specific customer situations that the coaching is designed to improve. Supervisors who over-emphasize this type of coaching realise a lift of more than 12% in their team’s performance.
The best supervisors focus roughly 75% of their coaching on integrated coaching.
Make It Real
Use creative approaches to help teams quickly understand what qualifies as more or less effort for the customer.
>Sharing of personal customer experiences – Have teams share bad customer service experiences from their personal lives.
>Group quality assurance sessions– Prescreen old customer calls and discuss high effort instances to build awareness and socialise the idea of customer effort reduction.
>Customer Effort Diaries – Get together and share their specific stories – capture specific instances when each person felt they did a great job of reducing effort.
Key Lessons from Early Adopters
Don’t make Effort Reduction another ‘Ask’
Reducing the no. of things frontline staff are being asked to focus on means that they can make effort reduction more of a priority, not just another ask.
The commitment to reducing effort, and the permanence of that approach, needs to become a shift in expectations, not just a new expectation added to the top of the pile.
“In order to get new behaviours to take hold, old behaviours have to be retired”
Baby Steps
Start with a small number of ways to reduce effort to make the shift more tangible to your teams.
This way, people know precisely what to do, and they develop a more refined sense for how effort reduction works.
Supervisors also have a finite set of behaviours to coach for.
Narrowly scope initial pilot expectations for your teams. This may include forward-resolving a specific type of service issue, or using positive language techniques for some common issues.
Lay the Cultural Foundation
Effort reduction is not a quick-hit project. It is service philosophy.
****
Reducing effort is an ongoing challenge you will need to continuously support.
You need lots of top-down communication, good manager and supervisor support, and the right metrics.
Your priorities should be a great change story, significant coaching discipline, and clearly signalling the expectation that a low-effort experience should be the goal with every customer.
Making it easy for your teams to take the first steps towards reducing effort will ensure your likelihood of success!
testwithnishi 