Category: articles

Must have skills for Agile Testers – a key to the entire team’s agility

Nishi Grover GargLeave a comment

Software test professionals have shouldered the responsibility of ensuring a quality software delivery. With the advent of agile, testers in agile teams have had a lot more in their plate. Instead of being a quality ‘gateway’ or checkpoint at the end of the software development life cycle, they have become an integral part of each and every phase of creation.

As I like to say, testers are key to the team’s agility and have a crucial part to play in the success of the project as well the team’s agile journey.

In my article published on ATA Agile Testing Alliance blog website at https://atablogs.agiletestingalliance.org/agile/must-have-skills-for-agile-testers-a-key-to-the-entire-teams-agility/ , I discussed the skills and thoughts that every agile tester must focus on to stay abreast with their project’s needs as well as the industry’s pace. Here are excerpts from the article:

—-

Be the User’s Amigo

Agile talks about the ‘3 amigos’ – the Business Analyst, the developer and the tester – all working together to bring a user story to life. To understand the user’s perspective on each and every requirement, a tester can play a crucial role by thinking ahead, asking the right questions during story grooming and design discussions and testing the most probable and useful paths while execution.

QA professionals are also required to think from the user’s chair and provide constant feedback during continuous involvement in usability testing, cognitive walkthroughs, focus groups and surveys etc.

Overall, an agile tester needs to think of the customers as their amigos, have a taste of their experiences, keep note of their problems and bring out the best in the software to keep their buddy happy!

 Learning Areas: Requirement Analysis, Use Cases and User Stories, Usability study, End-to-end testing, exploratory testing and test techniques

 

Keep a check on the ‘Behavior’

The requirements from the market need quick gathering, distillation and development which require collaboration between the entire set of stakeholders in short time scales.

Behavior Driven Development (BDD) uses the concept of ubiquitous language or a semi-formal language which is shared by all team members including developers, testers, business analysts and other non-technical stakeholders. It makes use of simple domain specific language to convert natural requirements into executable tests.

BDD is definitely catching up in the market because of its outside-in, multiple stakeholder and high automation approach suitable to agile projects. So, all my tester buddies, get your hands into BDD and related tools!

Learning Areas: Basics of TDD, BDD, Cucumber, ATDD, Fitnesse, building a Test automation framework

Spin the wheels of ‘Continuous Testing’

Software delivery timelines have reduced tremendously and to meet the expectations of quick delivery and deployments, software testing has to become a part of the delivery pipeline. The advent of DevOps has brought with it various tools to support CT as a part of CD which makes testers an integral part of the devops system. Software testers are required to participate in setting up and maintenance of sustainable test setups and environments, automate tests rapidly, set up and maintain the continuous testing pipeline.

Learning Areas: DevOps fundamentals, Configuration Management Tools, Build automation, Test automation tools and integration into devops pipeline

 

It is all black and white!

Testers focussing solely on ‘black’ box testing and only business level tests would need to think more ‘white’ now. The need of continuous testing can be met only by ensuring API level tests, and moving towards micro services testing which ensures easy test and deployment of new independent pieces of functionality in the code.

With faster delivery cycles, huge interdependencies of systems in real-time and regression overloads, functional tests are insufficient and impossible to run in isolation. For comprehensive tests, API testing will be the foremost requirement to verify dependencies on and with other applications and systems. Adding white box testing skills to their profile will not only be a value add to the resume, but also add an essential key piece to complete the ‘black and white’ picture.

Learning Areas: White Box testing basics, REST APIs, Unit test framework like JUnit, TestNG etc.

 

A tester’s role in an agile team is to provide assistance and support in all areas, so they may need to switch hats frequently, depending on the team’s needs. The success of this endeavour, though, also depends on an open, communicative, and receptive environment fostered within the team. Adding these new skills to your hat can help any agile tester bring more value to their team.

Happy Testing!!

 

Paying Off the Technical Debt in Your Agile Projects

Nishi Grover GargLeave a comment

Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.

Learn about managing your technical debt and testing debt in agile teams and share your thoughts on my latest article published at www.stickyminds.com and also at www.agileconnection.com

***** Here are some excerpts from the article for my readers***

Technical debt initially referred to code refactoring, but in today’s fast-paced software delivery, it has a growing and changing definition. Anything that the software development team puts off for later—be it smelly code, missing unit tests, or incomplete automated tests—can be technical debt. And just like financial debt, it is a pain to pay off.

Forming a Plan to Pay Off Technical Debt

Let’s say a development team working on a new project started out following a certain programming standard. They even set up an automated tool to run on the code periodically and give reports on the adherence to these standards. But the developers got busy and stopped running this tool after a sprint or two, and when the development manager asked for a report after a couple of months, there were hundreds of errors and warnings, all of which now need to be corrected.

This scenario happens all the time with agile teams focused on providing as much customer value as possible each sprint. The problem then needs to be fixed immediately, because despite having all the functionalities in place, the team doesn’t want to release code that is not up to production standards.

The team is then faced with a few options for how to service the debt:

  • Negotiate with the product owner on the number of user stories planned for the upcoming sprint in order to have some extra time for refactoring the code
  • Dedicate an entire sprint to code refactoring
  • Divide all errors and warnings among the development team and let them handle the task of corrections within the next sprint, along with their regular development tasks, by scheduling extra hours
  • Plan to spread this activity over a number of sprints and have a deadline for this report before the end of the release
  • Estimate the size of refactoring stories and either plan them into upcoming sprints as new user stories or accommodate them as part of existing user stories

Though these are all viable options, the best approach depends on the team, the context, upcoming deadlines, the risk the team is willing to take, the highest priority for functionalities that need to be shipped, and the collaboration with the product owner.

Again, just like when you take out a financial loan, you should plan to pay off technical debt as quickly as possible using the resources you have. It’s a good idea to perform a risk analysis of the situation and reach a consensus with the team about the best approach to take.

Technical Debt in Testing

Technical debt doesn’t occur only in programming. Testing activities are also likely to incur technical debts over time due to a variety of factors, including incomplete testing of user stories, letting regression tests pile up for later sprints, not automating essential tests every sprint, not having complete test cases written or uploaded to test management tools, not cleaning up test environments before the next iterations, and not developing or testing with all test data combinations on the current features.

Sometimes debt may be incurred intentionally for a short term, such as not updating tests with new test data when testing on the last day of the sprint due to a time crunch, but planning to do it within the first couple of days in the next sprint. As long as the team has an agreement, it’s acceptable to defer some technical debt for a short while.

On occasion, debt may be incurred intentionally for a longer term by planning it in advance, such as deciding to postpone any nonfunctional tests, like performance or security-related tests, on the system until a few sprints are out and features are stable enough to carry out the tests. Again, as long as the team agrees with the risk and has a plan to address it, it is fine to defer certain activities.

Testing technical debt can get us out of tight situations when needed, but you still need to ensure that you plan carefully, remain aware of the debt, communicate it openly and frequently, and pay it off as soon as possible. Having a plan to service these debts reduces your burden over time and assures your software maintains its quality.

Debt-Solutions

Prevention Is Better Than Cure

Avoiding having any technical debt is always preferable. As the saying goes, an ounce of prevention is worth a pound of cure.

Every team has to devise its own strategy to prevent technical debt from accumulating, but a universal best practice is to have a definition of “done” in place for all activities, user stories, and tasks, including for completing necessary testing activities. A definition of “done” creates a shared understanding of what it means to be finished so that everybody involved on the project means the same thing when they say it’s done. It becomes an expression of the team’s quality standards, and the team will become more productive as their definition of “done” gets more stringent.

Here’s a good example of criteria for a team’s definiton of “done” for every user story they work on:

  • All acceptance criteria for the user story must be met
  • Unit tests must be written for the new code and maintain a 70 percent coverage
  • Functional tests must be performed, and exploratory tests must be performed by a peer tester other than the story owner
  • No critical or high severity issues remain open
  • All test cases for each user story must be documented and uploaded in the test management portal
  • Each major business scenario associated with the user story must be automated, added to the regression test suite, and maintain a 70 percent functional test coverage

Verifying that the activities completed meet these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality, but in terms of quality as well. Adhering to this definition of “done” will ensure that you do not miss out on essential activities that define the quality of the deliverable, which will help mitigate the accumulation of debt.

Despite best practices and intentions, technical debt often will be inevitable. As long as the team is aware of it, communicates openly about it, and has a plan in place to pay it off as quickly as possible, you can avoid getting in over your head.

*************

‘INVEST’ing in good User Stories

Nishi Grover Garg1 Comment

User stories are the requirement specifications in their simplest form. Methodologies like Scrum use User story format to express the functional requirements of the software to be developed as –

As a <user persona>, I want to <do the action> so that <need of function>

This creates a deeper understanding of the behavior from a user’s perspective along with the business need and reason for the function, thus making the development of software easier.

But writing effective user stories isn’t as easy as it sounds. There are a lot of questions to be answered, like which functionality is one user story and which is too big and needs splitting up; what is the true sense of the user story; how to best express the functionality in words; which user personas are to be considered etc.

Getting the user stories right is an essential step to success of the sprints in agile, and for the teams struggling with it we have the INVEST principal as a guideline to be followed. This principal gives the attributes of a user story to be considered when writing and defining them so that they can make a robust foundation to our product backlog. Let us look at the principle in depth –

I – Independent

Means that each user story must be Independent as a functionality and be deliverable

N – Negotiable

Means that the user story be negotiable in terms of implementation, which necessarily means that the implementation details or ‘how’ to do the functionality must not be specified in the user story. User story must be business need and customer experience story.

V – Valuable

Means that the user story must create value for the customer. We should be able to see the reason and way the function will be valuable to the customer and this can be gauged by direct communication with the stakeholders, and can also be quantified in terms of ‘business value’ that we can associate with each story.

E – Estimable

Means that the User story must be clear and concise enough so that we can estimate the amount of work required to achieve it with accuracy. Any unclear parts, missing information or discrepancies must be clarified before we can finalise a user story to be taken up for development.

S – Small

Means that each user story must be a small chunk or slice of work. The development of one user story must be doable within one sprint and hence anything bigger than that would need to be further split down.

T – Testable

Means that each user story must be testable as a feature and have a unique new function get added to the product.

Letter Meaning Description
I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.
S Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible.

Keeping these points in mind when designing and formalising our team’s user stories will ensure that the sprint runs smoothly without unforeseen scenarios, glitches in implementation due to unclear requirements and re-work due to frequent changes.

Have more questions? How to achieve this?

Stay tuned for the next article where we will look at the steps to achieve the best user stories.

Happy Testing!
Nishi

 

Let the ‘Agile Manifesto’ guide your testing efforts!

Nishi Grover Garg4 Comments

Hello readers

My article on the relationship of Agile Manifesto to the efforts and dilemmas of software testing has been published at stickyminds.com

Here are excerpts from the article – Please visit https://www.stickyminds.com/article/let-agile-manifesto-guide-your-software-testing and share your views too!

The Agile Manifesto is the basis of the agile process framework for software development. It sums up the thought process of the agile mind-set over the traditional waterfall methodology, and it’s the first thing we learn about when we set out to embrace an agile transition.

The Agile Manifesto applies to all things agile: Different frameworks like Scrum, DAD (Disciplined Agile Delivery), SAFe (Scaled Agile Framework), and Crystal all stem from the same principles.

Although its values are commonly associated with agile development, they apply to all people and teams following the agile mind-set, including testers. Let’s examine the four main values of the Agile Manifesto and find out how they can bring agility to teams’ test efforts.

agile-manifesto

Individuals and Interactions over Processes and Tools

Agile as a development process values the team members and their interactions more than elaborate processes and tools.

This value also applies to testers. Agile testing bases itself in testers’ continuous interaction and communication with the rest of the team throughout the software lifecycle, instead of a one-way flow of information from the developers or business analysts on specific milestones on the project. Agile testers are involved in the requirements, design, and development of the project and have constant interaction with the entire team. They are co-owners of the user stories, and their input helps build quality into the product instead of checking for quality in the end. Tools are used on a necessary basis to help support the cause and the processes.

For example, like most test teams, a team I worked on had a test management system in place, and testers added their test cases to the central repository for each user story. But it was left up to the team when in the sprint they wanted testers to do that. While some teams added and wrote their test scenarios directly on the portal, other teams found it easier to write and consolidate test cases in a shared sheet, get them reviewed, and then add them all to the repository portal all at one go.

While we did have a process and a tool in place to have all test cases in a common repository for each sprint, we relied on the team to decide what the best way for them was to do that. All processes and tools are only used to help make life easier for the agile team, rather than to complicate or over formalize the process.

Working Software over Comprehensive Documentation

With this value, the Agile Manifesto states the importance of having functioning software over exhaustively thorough documents for the project.

Similarly, agile testers embrace the importance of spending more time actually testing the system and finding new ways to exercise it, rather than documenting test cases in a detailed fashion.

Different test teams will use different techniques to achieve a balance between testing and documentation, such as using one-liner scenarios, exploratory testing sessions, risk-based testing, or error checklists instead of test cases to cover testing, while creating and working with “just enough” documentation in the project, be it through requirements, designs, or testing-related documents.

I worked on an agile project for a product where we followed Scrum and worked with user stories. Our approach was to create test scenarios (one-liners with just enough information for execution) based on the specified requirements in the user story. These scenarios were easily understood by all testers, and even by the developers to whom they were sent for review.

Execution of test scenarios was typically done by the same person who wrote them, because we had owners for each user story. Senior testers were free to buddy test or review the user story in order to provide their input for improvements before finalizing the tests and adding them into the common repository.

Customer Collaboration over Contract Negotiation

This is the core value that provides the business outlook for agile. Customer satisfaction supersedes all else. Agile values the customer’s needs and constant communication with them for complete transparency, rather than hiding behind contract clauses, to deliver what is best for them.

Agile testing takes the same value to heart, looking out for the customer’s needs and wishes at all points of delivery. What is delivered in a single user story or in a single sprint to an internal release passes under the scrutiny of a tester acting as the advocate for the customer.

Because there is no detailed document for each requirement, agile testers are bound to question everything based on their perception of what needs to be. They have no contract or document to hide behind if the user is not satisfied at the end of the delivery, so they constantly think with their “user glasses” on.

As an agile tester, when I saw a feature working fine, I would question whether it was placed where a user would find it. Even when the user story had no performance-related criteria, I would debate over whether the page load time of six seconds would be acceptable. After I saw that an application was functionally fine, I still explored and found that the open background task threads were not getting closed, leading to the user’s machine getting hung up after few hours of operation. None of these duties were a part of any specification, but they were all valuable to the user and needed correction.

Responding to Change over Following a Plan

Agile welcomes change, even late in development. The whole purpose of agile is to be flexible and able to incorporate change. So, unlike the traditional software development approaches that are resistant to change, agile has to respond to change and teams should expect to replan their plans.

In turn, such is the case for agile testing. Agile testing faces the burden of continuous regression overload, and topped with frequent changes to requirements, rework may double itself, leading to testing and retesting the same functionalities over and over again.

But agile testing teams are built to accommodate that, and they should have the ability to plan in advance for such situations. They can follow approaches like implementing thorough white-box testing, continuously automating tested features, having acceptance test suites in place, and relying on more API-level tests rather than UI tests, especially in the initial stages of development when the user interface may change a lot.

These techniques lighten the testing team’s burden so that they can save their creative energies to find better user scenarios, defects, and new ways to exercise the system under test.

Let the Agile Manifesto Guide Your Testing

When agile testers have dilemmas and practical problems, they can look to the Agile Manifesto for answers. Keep it in mind when designing and implementing test efforts; the Agile Manifesto’s values will guide you to the best choice for your team and your customers.

If you are interested in learning more about the Basics of Agile Testing, here is an interesting post for you!

Hope you liked my write-up, please share your views too!

Happy Testing!

Nishi

5 Ways Agile Testing Is Different from Traditional Testing

Nishi Grover Garg3 Comments

My latest article for stickyminds.com focused on the essential differences between Agile and traditional approach of testing >> published here

****

The agile world is abuzz nowadays with talk about agile testing and the key role of testers in an agile project. Some even say testers are the key piece of an agile team, arguing that they define the success or failure of the team’s attempts to be agile.

But what makes agile testing different from traditional testing? It’s the distinctions between the agile and traditional software development approaches, but also the adaptability of testers in these very different environments. Agile demands more from its testers, and, in turn, it values them more, too.

Let’s look at five main things that make an agile tester’s life different from that of a traditional tester.

Continuous Involvement

In traditional projects, the test team works mostly in a silo, and there is little or no interaction needed with developers or other teams on a daily basis. But in agile, the test team is integrated with the Scrum team instead of being a separate unit. They need to be continuously involved in all aspects of the project, starting with the requirements and design of each feature. This makes the testers’ days busier with discussions, meetings, and interactions where they need to put forward their opinions.

Agile necessitates that everybody report to the Scrum team first and their separate testing or development team later. In my experience as a part of a Scrum team, we would discuss our vacations or skill training needs first within the Scrum team, then inform our test manager afterward.

Essential Tools

Agile needs tool support more than traditional projects do because of the pace of development and continuous iterations. Each iteration brings along some regression work from the previous iterations that needs to be automated quickly.

The same is true for test data generation, white-box testing tools, and static analysis tools, which become a necessity in an agile system. Given the time and quality constraints, performing white-box tests using control flow or data flow analysis, static analysis of code, or reviews for code and documents is no longer optional. Instead, it’s a mandate to prevent defects and ingrain quality into each work product.

While in traditional projects, tools may be a luxury we might not be able to afford, in an agile project they become a necessity. Testers need these tools’ abilities in order to achieve their quality targets.

When my team began our agile transformation, we had one automation engineer who would work on automation scripts for the entire project. But when pacing through the sprints, we quickly realized that one automation engineer was not able to keep pace with automating all features in all sprints. So, everybody started pitching in by scripting the features they tested, and eventually it was mandated. The automation expert was only used for framework-level implementation, and later he was absorbed as a functional tester.

Due to frequent changes in the application within the sprint, we would follow an (n–1) approach to automation of our product, automating the features of the nth sprint in the next sprint, then subsequently using them for regression. But due to overload of regression building up as we progressed, it was crucial that each tester be able to perform and use the tools effectively, building up the test suites every sprint.

Multidimensional Skills

A traditional project has set expectations from the testers and testing activities. Each phase of testing gives set outputs, such as test design and specifications in the design phase, functional issues and defect reports in the execution phase, regression tests and retest results in reruns, and acceptance test reports in the end phase. This pattern does not leave much room for anything else because the project is already hard-pressed at the deadline.

But an agile tester’s viewpoint covers not only the functional aspects of what he is testing, but also many broader aspects of the application. He need not be a performance testing expert to suggest during the design discussions that the design might not be able to support too many users. He may not be a usability expert, but he can suggest better ways to design the web form of their user story. He may not be a technical writer, but he may be required to review the installation guide steps. An agile tester has to have a broader perspective of quality in his project’s context and possess skills in all those areas.

Effective Communication

Agile requires effective communication among the team members at all times, and testers play a key role in establishing and maintaining that. For example, as a part of a Scrum team, a tester will be required to wear many hats: that of a requirement critic for the product owner, of a design reviewer for the developers and architects, of a functionality expert as a tester, and of a release adviser to the manager. Testers have to give their opinions and ideas at all stages of the project, which may be not required (or even much welcomed) in a traditional project.

Testers act as the binding force of the team when they work in pairs with developers, sharing their test cases and ideas, as well as when they work as a quality reporter for the manager, with daily statistics and defect metrics for each sprint. The art of verbal and written communication is essential in an agile project.

Quick Feedback from Testing

The most important difference for agile testers is the quick feedback being given from the testing perspective at every point. The agile timeframes are shorter than on a traditional project, and testing needs to provide feedback about project quality on a regular basis. Daily stand-up meetings, design discussion or review meetings, the user story verification status, and sprint retrospectives all require constant feedback from testers.

There is some additional pressure because the direction of the project gets defined by this feedback, and there is no final “quality gateway” at the end if the project does not meet the deadlines or quality goals. This keeps the testers on their feet at all times, unlike in traditional projects where testers are required only at the end of the project for a sign-off.

Working in an agile environment can be challenging for testers coming from traditional projects, but by being open, flexible, and adaptive, they will find that an agile team is a wonderful place to be a tester.

Do share your views!

Cheers

Nishi

Agile Tester, ISTQB and more – What I gained v/s what I didn’t from all these certifications

Nishi Grover Garg18 Comments

I am glad to share the latest article I wrote for utest.com forum of testers globally as a part of their #BackToSchool campaign – where writers are sharing their experience with formal education , degrees and certifications on their profession.

I was excited as soon as I read about the #BackToSchool campaign on http://www.utest.com. As someone who has 5 certifications and numerous conferences to my credit, I definitely needed to share my insight and experience here.

Please read and like my article on the forum at

https://www.utest.com/articles/agile-tester-istqb-and-more-what-i-gained-vs-what-i-didnt-from-all-these-certifications

certi

For a background – I am certified by ISTQB at – Foundation Level (CTFL), Advanced Level Test Analyst (ISTQB Adv TA) and Certified Test Manager (ISTQB Adv TM).

I am also certified by Agile Test Alliance ATA body at 2 levels—Master Agile Tester (MAT) and Automation Agile Tester (AAT)

Just to clarify– none of these certifications were a mandate for my job or a part of my yearly ‘goals’ as some companies I have now heard do to their entry or mid-level testers.

Why did I take these up?

I took up all these certification exams at different points of my career for different purposes.

When I started out my career, I was working as a tester in a start-up like company where I had minimum guidance or hand-holding into the testing world, its terminologies and processes, during being responsible for a huge project in its nascent stage. After about a year of working I had begun to realize that there were some things missing in my knowledge. Though I had learnt about writing test cases and had gotten pretty good at finding bugs and reporting them, I hardly knew the broader perspective of why we did what we did and what the industry outside was working with. I did not have any software background before that and did not study it in my college course too. So I decided to take up some kind of course of learning about the basics to gain confidence about my own work. I looked up online and found out about ISTQB which seemed to be the most popular course and certification for entry level software testers. I started to study for the same. I bought a book, researched online, and did self-study instead of taking up a training course. The course is designed to open up the complete picture of software testing world in front of you so that being in any industry or domain or level of testing, you can relate to where you are and what is the process around you. Every day I learnt about more types of testing that can be done, what they meant. I appeared for the exam and cleared it. But the purpose it solved for me was more than the certification. It was making me confident about what I was doing, what improvements I could suggest in my processes and even what terms we were using wrongly in our team. It also made me stand out amongst my peers – not because of the certificate only (start-ups hardly care about that right) but because of this drive to improve myself and my team and the knowledge I could now share.

Note – That is why I suggest the best time to do this exam is at the onset of your testing career, probably up to 2 years into it.

This later inspired me to take up the next level (ISTQB TA) which is supposed to be an extended level for functional testers at a senior level. I studied for the course just the same, but the exam experience was a lot different from the foundation level. It was a more scenario based exam wherein I had to apply the learnt lessons into real-world like situations and exercise decision-making. That was fun – and probably that is a reason why the pass-rate is so much lower for advanced levels.

After a couple of years of doing both these, I felt now I had reached a place where they did not suffice my needs. I was in a dynamic team working in Scrum and needed a more hands-on learning. I wanted to interact with people outside my team. I looked up online and stumbled upon ATA and their 3-day program happening in a nearby city. I talked to my company and being the supportive group they were always, they agreed to sponsor me! So, I went and participated in the CP-MAT (Certified Professional-Master Agile Tester) program by ATA. Now, that was fun! I met a small group of people from different companies and had deep discussions on their experiences, the trainers who had fun team exercises planned all along and a very hands-on final exam which required actual agile tester skills.

A month after it, ATA approached me and invited for their next level training and also offered me a train-the-trainer program since they liked my drive and skills. I was interested to give it a try and so decided to go for that. I did not ask for sponsorship again from the company though, just the leaves for those days. So, I went ahead and did the CP-AAT program which was based on behaviour-driven development using Cucumber tool and its integration with Fitness tool. Since my team was not into any of these practices, I never got to use the knowledge I gained in this program. So I thought it was too specific and confined.

So, now you know about why I did each of these and that they just sort of happened over my 8+ years in the industry.

What I gained from them?

As I explained, from my first ISTQB CTFL and TA certificates, I gained insight into correct testing processes and terms, and knowledge about the things that were not happening in my team. This gave me confidence that I was relevant around the industry and to share opinions in the team at an early stage in my career. But yes, it definitely also was a plus that I could put it in my resume and increase my chances of being shortlisted for interviews, because many companies find it as a plus.

From the Agile Testing certifications I gained the insight into agile and how testing should fit in and all the hats a tester must wear for the team to succeed. Since then I progressed into a mentor and leader’s role and also acted as a scrum master and agile pod leader, so it must have helped in some way.

It didn’t hurt that it also brought some credibility and value to my profile. So, when I had to move to another city and find a new job a year later, I wasn’t worried about the switch because of the background I had created for myself. It also pushed up my biography when I wanted to submit proposals to talk at national level conferences and I got the opportunity to speak there.

What I did not gain from them?

Please be sure that though some companies may give preference to certified candidates or they may get shortlisted quicker, but a certificate can never replace actual knowledge. The interview process has to ensure that you have practical experience and knowledge instead of just having cleared a few exams.

Agile teams, start-up teams and communities like u-test do not require any kind of certificates, they need real skills.

If you have worked extensively around the industry and gained that experience, good enough!

If you have self-taught yourself by keeping updated with different skill sets, good enough!

If you have had great mentors who have guided you through the learning, good enough!

If you have studied for different courses and learnt the skills of the industry, good enough!

Conclusion:

All study must be done with the aim of learning and gaining some skills and not to get some certificate. The advantages of having the certificate are shallow and short lived as compared to the learnings you get. Do a course only if it has relevance for the level and point in your career and if you have learnt enough without it, so be it. Some certificates even require to keep upgrading or reappearing every few years to ensure that your skills are still relevant.

The real knowledge will come from practical application of the learnings and skills and that is what will distinguish you from the crowd!

Happy Learning!

—– This post has been later featured by The Pirate Tester in 2019 in his blog at –>

https://thepiratetester.wordpress.com/2019/06/18/2019-06-18-should-istqb-exist/

Are you ‘guessing’ your tests?

Nishi Grover GargLeave a comment

Like everyone of us , many teams struggle with test creation due to miscommunication or a lack of requirements, testers not being present during design phases or discussions, a shortage of time, or incomplete information. But that doesn’t mean you should turn to guesswork. Your tests will suffer in quality and completeness. We must always strive to get the desired requirements.

My article on the same topic has featured on Techwell community’s website www.stickyminds.com , titled

“Don’t Guess Your Tests—Strive for Complete Requirements”

Here are some excerpts from the article –

Test creation is perhaps the most important aspect of software testing. Though most of our focus is on test execution and reports generation because that is the most visible output testing has, the backbone of the entire process lies in the creation of accurate and meaningful tests.

Many teams struggle with test creation during their agile journey, and they often seem to be doing a lot of guessing during test design or creation. This can be due to miscommunication or a lack of requirements, testers not being present during design phases or discussions, a shortage of time, incomplete information about which test environment or tools to use, or unknowns such as relevant positive and negative scenarios to test or overall purpose and scope of the application.

Hurried guesswork during test creation leads to bigger problems later in the project and poses a risk to the overall quality of the product.

Say your team has to test a webpage. Apart from some functional specifications about controls on the page, they do not have much information. But they have so many things to decide on before starting to test, such as what browsers to test on, which tool to use for automation based on the types of controls to be identified, what workflows to execute as part of integration testing of this page with the entire website, and so on.

It is also very important that those functional specifications about the webpage, its controls, and validations on each control are complete and thorough. When the team is designing and creating the test plans and test scenarios, ambiguous or missing requirements would lead them to assume a lot of parameters and guess some cases according to personal perceptions. For instance, a tester may assume Chrome should be the web browser under test and start using his installed version as the default without asking for customer preferences and all the versions that need support.

Suppose a username field on the webpage does not specify its upper limit and allowed characters validation in the specification. The tester may assume it to be a standard ten-character limit with only letters allowed and start testing accordingly, without asking relevant questions about regional and domain specific requirements. If the website has French users whose names contain special characters, or Indian users whose names frequently exceed ten characters, these inputs would fail from the tester’s assumptions and guesswork applied during testing.

Another problem teams may face is guessing test data. Are you using proper techniques to derive test data values, or just guessing random values to input? Suppose you are testing the function of addition. Are you randomly sending inputs of numbers and verifying the output? We should be using proper design techniques such as equivalence class partitions or boundary value analysis to derive a proper set of test values.

This is how poor communication or a lack of direction results in bad test design. We need to minimize this guesswork and make informed decisions before we begin the actual testing.

Getting Testers Involved in the Requirements Phases

My team was quick to realize this when we faced missing and vague requirements in one of our agile projects. We noted that due to a lot of factors mentioned above, we were subconsciously assuming things when designing tests and later on realizing our assumptions were incorrect, meaning many of our defects were marked invalid and we had to redo a lot of work. We decided to fight this problem.

The testing team started to request that we be allowed to participate during requirements phases, in user story fabrication as well as design discussions. This led to better clarity on a lot of requirements and functionalities, but it also ended up helping the entire team because we raised questions on the requirements and designs from a testing perspective and helped make better documents from the user stories, which later formed the basis of our tests.

The role of communication cannot be stressed enough here. We encouraged our teammates to ask the development team for more information—what to test, which environments to use, what could impact our testing, etc.—and our tests based on these solid facts and details were much more useful and successful.

Another good idea was involving the entire testing team, instead of having one or two team members create tests while the others just worked on executing them. We shared the details of the functionality to be tested with all the testers involved, and everyone collaborated on creating tests. With everybody giving their perspectives and opinions and challenging each other’s assumptions, our tests were bound to be more elaborate and exhaustive.

Reviews formed an important aspect to unbind the scope of our tests. We got peer testers, developers, test managers, and product owners to do some buddy reviews on our tests to ensure that we were not limited in our imagination and perspective. This opened up a lot of untouched areas and left no room for guesswork! It also gave us confidence that everybody had signed off on the designed tests, so it was unlikely that later on our defects would be valid.

If you don’t have enough information or communication to create your tests, that doesn’t mean you should turn to guesswork. Your tests will suffer in quality and completeness. We must always strive to get the desired details and only then create our tests based on solid grounds. This will eventually result in a lot less rework and much more valuable testing.

—

Please share your thoughts and follow the blog for more such interesting reads!

Happy Testing!

 

 

The Real Key to Agile Success: Communication

Nishi Grover GargLeave a comment

Dear Readers,

I am glad to share that my latest article found its way to agileconnection.com !

Here are some excerpts from the article –

Many organizations have issues during the transition to an agile workflow. Some teams never quite recover from that transformation stage; they say they tried agile but it didn’t work for them, or they are still struggling to get it going. If we look for the real reason behind all these troubles, I bet the majority fo the time, it would be communication.

Agile is designed for smaller that want to get more done with fewer formal processes. Iteratively building and demonstrating the desired products for more immediate feedback is the goal.

Think about the common practices of an agile team: daily stand-up meetings, retrospectives after every sprint, pair programming and buddy reviews, collaborating with customers, and more face-to-face time instead of mountains of documentation.

What is the agenda behind all these operations? Frequent and open communication.

Agile teams are designed so that everybody is aware of everyone’s tasks, progress, strengths, and output each day. The difficulty is communicating all this information.

Let’s say a team was working on a sprint with some defined user stories. The team started working on their assigned stories, using what little was specified in the requirements and assuming the rest. Nothing much was brought up in the daily stand-up meetings, which were short and missed often. The developers worked on their stuff, and in the last few days of the sprint passed their code on to the testers, who began their test design parallel to the test execution. Most of the testing was done in an exploratory fashion, owing to the lack of information and time.

Of course, problems arose. Testers blamed faulty designs and the lack of information provided to them. In turn, the developers blamed the specifications. The manager—who was missing for most of the sprint—now appears and questions the team about the quality issues. Most of the user stories become spill-over items to work on during the next sprint due to the design changes needed.

Unfortunately, this is probably not an unfamiliar situation for many of you. An agile team can’t succeed if communication is lacking.

The team in the example earlier could have done much better if they had nurtured their communication skills. The developers should have discussed the specifications and pointed out missing or ambiguous aspects to the manager, who then would have talked to the clients to get clarifications. The test team should have been involved in all these communications, building their tests in parallel and getting them reviewed. Developers and testers should have coordinated their user stories to buddy test the features and get maximum issues resolved in advance. And everyone should have been participating in stand-up meetings to communicate progress and risks. If this had happened, by the end of the sprint the user stories would have been resolved, and the team could have delivered a better-quality product.

Naturally, it’s easier to look at a failed project afterward and point out what should have been done differently. How can you set your team up for success from the beginning? Before even seriously considering the logistics of agile adoption, you should start looking at all aspects of communication in your teams.

The assigned ScrumMasters must have the ability to communicate and manage the team well, as well as encourage teammates to speak their minds. The agile team may need some verbal or written skills training if they are not used to informal communications via chats, email, or short documents.

All communication within the agile team must be addressed to the complete team, including sharing any documents, release plans or schedules, review requests and feedback, risks or concerns, and even leave updates. This builds a complete sense of oneness within the team and maintains complete transparency at all times.

The managers and leads must ensure open communication and healthy feedback during all meetings and also encourage team members individually to share their ideas and opinions. Likewise, the team must be receptive to constructive criticism and ready to learn from their mistakes.

Only in such an environment will the real agile spirit thrive and teams will be able to find success in their endeavors.

Pages

Read the complete article and do share your thoughts!

https://www.agileconnection.com/article/real-key-agile-success-communication

5 Ways Testers Can Mitigate Practical Risks in an Agile Team – @Agileconnection.com

Nishi Grover Garg2 Comments

Dear Readers,

Last week , my latest write-up got accepted and published on the renowned forum agileconnection.com –

Do check it out at http://www.agileconnection.com/article/5-ways-testers-can-mitigate-practical-risks-agile-team

Here are the excerpts from the write-up :

———————————————–

Testers who analyze quality in every aspect of the team’s deliverable also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.

SAMPLE SCENARIO:

Let’s say an agile team has a user story to develop a webpage in a sprint. The product manager mentions only the mandatory fields of the webpage in the story’s description while scoping it in the sprint. The developer works on the story for a couple of days and adds the listed fields on the page, but because he going on leave for a few days, he only provides the basic form fields without any input validations or error messages on the page.

Once back from his vacation, he checks in the code and shares it for testing a day before the sprint ends. The tester tests it for a day and raises some minor severity issues. In the final sprint demo, the product manager points out that a number of fields are missing on the webpage. Because testing is not complete yet, the story is tagged as a spill-over item to the next sprint. Few UI changes are added in the next sprint’s scope, along with the pending validations and error messages.

What do you think went wrong in this story?

Agile is all about controlling and minimizing the typical risks of conventional software development techniques. When working with agile, we have the flexibility to control our direction and steer our path based on unforeseen and unplanned changes and events.

But it is the same flexibility and dynamic nature that makes agile prone to many risks during the project.

These risks are the practical issues that any agile team is bound to face eventually and that, if not handled quickly, may lead to failure of the sprint or the agile process as a whole. Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate these risks and help the team succeed in their product as well as at being agile.

Here are five such issues that testers can help the team alleviate or avoid.

Five
The power of Five!

Risk 1: Ambiguous User Stories

Agile assumes that each user story is a unit of work to be achieved in a sprint. The user story needs to be granular enough and have all relevant details and context when scoped. But because agile also recognizes changing requirements as likely, this gets used as an excuse to not list the requirements for each user story or give details early on. This leads to ambiguous requirements, often resulting in low-quality outcomes and rework on the feature.

The actual aim of agile is to work on a feature based on the best knowledge of its requirements at the given time. The sprint format in the Scrum process leaves scope to work on a feature again if enhancement is needed. But that is based on collecting all available information for one story and only then scoping it in a sprint. If that is not ready yet, the story should not be scoped in the current sprint.

Testers in an agile team have the responsibility of reviewing user stories when they are being planned for the sprint and requesting clarification from the product management. Similarly, developers can raise questions about technical and design details they feel are missing and get them defined during planning sessions. Based on these details, testers will create their test scenarios around that user story, and developers will create their implementation design and keep asking more questions if needed over the next few days of the sprint.

In the example at the beginning, the tester could have raised the concern that the user story did not have complete details for the webpage to be developed while scoping it in the sprint. The developer should have asked about relevant validations and error messages needed, as well as some broad layout details to work with.

Risk 2: Not Delivering the Highest Business Value

When a sprint is in progress, developers may dig into their assigned stories and, in trying to get the more complicated things done, digress from the priority of each story. As testers, we constantly need to question the delivery of the most valuable features in the sprint so that we are sure to test and deliver them as early as possible.

During the sprint planning discussion, we must assign business priorities to each story being scoped in. The sequence in which the stories will be delivered will depend on that.

Testers may also raise concerns when more time will be needed to test a feature, and request for it to be delivered early so that the testing can be completed well within the sprint deadline.

At all times we must assume that only the stories that are done from both development and testing perspectives are the ones that are designated as delivered in the sprint final build.

In the example, the developer could have shown the developed page to the product manager and asked for feedback during the sprint to avoid multiple iterations. The tester should have asked for a buddy build for the story before the developer left for vacation to provide more testing time and get maximum issues within the sprint. This would have avoided the task needing to spill over to the next sprint.

Risk 3: Quality Concerns

During the sprint testing cycles, all issues found pertaining to a feature must be tagged with the relevant user story. This can be done easily by linking the issues together in the issue-tracking tool being used.

The testing team must decide on a tolerance threshold for the number of issues for each user story based on their severity, beyond which they would raise a quality concern against that story. Testers should then request these issues to be fixed before any further development is done on that story. This helps immensely in avoiding delivery of half-baked features with too many known issues yet to be fixed at the end of the sprint. This way, at the end of the sprint, all user stories are at a minimum quality benchmark with no obvious or critical issues. Of course, improvements and enhancements are always welcome and may be taken in further sprints.

In the example story,the tester should have raised maximum issues against the user story within the sprint and brought them to the product manager’s attention, along with missing or undelivered functionalities.

Risk 4: Resource and Time Conflicts

When working in a sprint format, the process is bound to be very fast-paced, with each team member being relied on heavily for the assigned user stories.

There may be parallel tracks or other activities, like performance improvements, code refactoring, white box tests, or documentation and reviews, that team members may be expected to handle, which, if they go beyond a number of hours per sprint, may hinder the sprint deliverables. It is the team members’ responsibility to bring any such activities to the ScrumMaster’s notice as risks during the daily stand-up meeting.

The testing team may raise any planned resource or time conflicts during the sprint planning session itself, so that estimation may account for these time losses. Team members also are expected to bring up any planned vacations or leave during the planning session so that their absence may be accounted for during estimation.

In the example story,the developer’s leave plan should have been taken into account when assigning the user story, and consequently, there could have been a co-owner of the story to take up the additional parts, such as implementing validations and UI improvements to the page while the developer was away.

Risk 5: Failures in Collaboration and Communication

Scrum ceremonies, such as the sprint planning sessions, daily stand-ups, triage meetings, and sprint retrospectives meetings, rely heavily on the team’s self-drive and total involvement. Without these factors, the ceremonies become mere formalities, adding little value to the process.

Testers in an agile team must be involved in every phase of the agile development process and raise concern if the team is not performing any of the ceremonies in the correct fashion. Only with full participation and regular communication can we actually achieve success as an agile team.

In the example, the team could have communicated more over the user story, talked to the product manager, and proactively gotten more information, details, and feedback during development. The tester could have initiated more discussions around the requirements and worked closely with the developer to highlight issues instead of waiting for the final build at the end of the sprint.

                                        A tester’s role in an agile team is to provide assistance and support in all areas, so they may need to switch hats frequently, depending on the team’s needs. The success of this endeavor, though, also depends on an open, communicative, and receptive environment fostered within the team. Following these basic pointers can make testing a fun and collaborative part of the agile environment and add a lot more value.

More such fun agile knowledge at : http://www.agileconnection.com/

Cheers,

Nishi

Innovation Games – Part 4 – 20 / 20 Vision

Nishi Grover GargLeave a comment

Hello Readers!

Here we have for you another Innovation Game centered around prioritization. It is a visual and crisp way to chart out and understand priorities of upcoming tasks , features or stories.

Game :   20/20 Vision

Aim :       To chart out the RELATIVE priorities of the tasks at hand

Method:  The 20/20 game elaborates the prioritization of each task in relation to a benchmark task of medium priority and complexity.

Just like a visit to the Optometrist, where he makes you compare the various lenses to find the best suitable for your sight, in this game we make the team compare all stories / requirements / tasks and find the right place for them on the chart of priority in relation to the one benchmark level.

Description: Write down all stories on post-its. With the team’s consensus and decision, decide on one story which is of medium level and put in on the board in the middle.

Now the team goes through each story one by one, and places the story on the board as higher or lower priority in relation to the benchmark story. At the end of the exercise, we arrive at a visual representation of the story or task prioritization, giving us a clear road-map for future!

20-20

This game takes almost 15-30 minutes only depending on the number of tasks at hand, as compared to long planning meetings.

Give it a try, it is fun ! 🙂

Cheers,

Nishi