‘Just Enough’ documentation in an Agile Project

Agile poses many challenges to the development team, most of them pertaining to time. Teams are perpetually under pressure to deliver working software at a fast pace, leaving minimum time for anything else. When testing on an agile project, learning how to write lean documentation can save precious time. Furthermore writing lean documentation can help rework efforts by focusing only on what’s really necessary.

The Agile Manifesto emphasizes working software over comprehensive documentation, but most agile teams interpret this wrong and treat documentation as something to be avoided, owing to time constraints. The manifesto states a lesser focus on comprehensive documentation, but some documentation is still needed for the project and any related guidelines being followed. Attaining this balance is a challenge.

Documentation is a necessary evil. We may think of it as cumbersome and time-consuming, but the project cannot survive without it. For this reason, we need to find ways to do just enough documentation — no more, no less.

Read about how to focus on important areas like VALUE  , COMMUNICATION and  SUFFICIENCY when documenting in your agile project – in my article published at Gurock TestRail blog –> https://blog.gurock.com/lean-documentation-agile-project/

just enough

Click here to read the full article

For example, in a traditional test design document, we create columns for test case description, test steps, test data, expected results and actual results, along with preconditions and post-conditions for each test case. There may be a very detailed description of test steps, and varying test data may also be repeatedly documented. While this is needed in many contexts, agile testers may not have the time or the need to specify their tests in this much detail.

As an agile tester, I have worked on teams following a much leaner approach to sprint-level tests. We document the tests as high-level scenarios, with a one line description of the test and a column for details like any specific test data or the expected outcome. When executing these tests, the tester may add relevant information for future regression cycles, as well as document test results and any defects.

More examples and scenarios for learning leaner test document creation are included in the full article– Click here to read the full article

 

                 Are you interested in finding the right tool for your Agile processes? Here is a comprehensive assessment and comparison of the best agile tools available! 

https://thedigitalprojectmanager.com/agile-tools/

Prepared by Ben Aston, this list may be a useful guide for finding and selecting the best tool to support your agile journey. Check it out!

 

Happy Testing!

Nishi

The 12 Agile Principles: What We Hear vs. What They Actually Mean

The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?

In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.

 

Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software

What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.

The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.

What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.

Principle 2:

Check out the complete post here —- Click Here to Read more–>

 

Do share your stories and understanding of the 12 Agile Principles!

Cheers

Nishi

My interview with Thomas Cagley featured on SPaMCAST

I recently had a chance to chat with Mr. Thomas Cagley in an interview for his wonderful Podcast channel SPaMCAST. We talked all about Agile Testing, its differences from the traditional approach of testing, Agile Pods and the upcoming trends in the testing world!

It was a wonderful experience and I am grateful for having the chance to talk to one of the people I so look up to in the industry. Here is the link to the podcast show notes and info

http://spamcast.libsyn.com/spamcast-516-agile-testing-and-more-an-interview-with-nishi-grover-garg

Here is the link for Direct Playback: bit.ly/2QKvPvm

 

Hear it out and do share your thoughts!

Cheers

Nishi

 

A Day in the Life of an Agile Tester

An agile tester’s work life is intriguing, busy and challenging. A typical day is filled with varied activities like design discussions, test planning, strategizing for upcoming sprints, collaborating with developers on current user stories, peer reviews for teammates, test execution, working with business analysts for requirement analysis and planning automation strategies.

In my article for Gurock TestRail blog, I have explored a typical day in the life of an agile tester and how varied activities and tasks keep her engaged, busy and on her toes all the time!

agile tester.png

Let’s sneak a peek into a day in the life of an agile tester — > You will go through the daily routine of an agile tester and will experience their complicated schedule in real time.

Read full article

https://blog.gurock.com/agile-tester-work-life/

 

ATA Bangalore 19th Meetup hosted @Coviam – Event Round Up

I, representing Agile Testing Alliance, organised and hosted the 19th ATA meetup @Bangalore on 28th July 2018 in association with CovaimTech . The event was themed as “The Future of Testing” and was aimed at bringing awareness on new trends in the world on agile, testing and devops.

Mr. Manoj Kumar Vijayaragavan (VP of QA Engineering, Coviam) gave an introductory talk about QA practices and technologies used at Coviam. We had speakers from Coviam present enlightening talks on topics like “Deployments at Scale” by Ankit Tripathi (DevOps Engineer) and “Integrating Microservices for continuous testing” by Viswanatha Reddy (Senior SDET, Coviam) , which were highly appreciated.

We also introduced for the first time in this meetup, the concept of Lightening talks, wherein we opened registrations for any interested delegate to take the stage and present any idea for a short 10-minute duration. This idea got two speakers Mr. SarathKumar M.V. presenting on Microsoft Azure testing capabilities and Mr. Rakesh Reddy talk about “Accessibility Testing Strategy”. The short and crisp talks brought out valuable discussions and garnered interest from the audience.

Our gracious hosts @Coviam had arranged for tea and we had a brief networking break.

Our third speaker was Ms. Bhavani Sruti from Moolya who presented a hands on session on Mobile App Performance Testing, wherein we engaged the audience in performing some tests on their own mobiles first-hand and explaining the various performance parameters for mobile apps.

The last segment of the meetup was the Agile Games. I along with Mr. Nagesh Deshpande from Cynosure had planned some quiz questions, and Pictionary words to play amongst the delegates divided into teams. The audience had the chance to win ATA goodies, and the teams were awarded with goodie bags! The delegates had loads of fun playing the games and thus the event ended on a high note!

Thus ending the event, we took part in lunch arranged, and discussing various other interesting ATA events coming up soon.

Here are a few glimpses of the event-

Talks-MeetupCoviamGames-MeetupCoviamFelicitations-MeetupCoviam

Looking forward to organising many more such events to encourage and bring together the testing community!

Cheers

Nishi

 

5 Mistakes to avoid in Agile Retrospectives

Retrospectives are an integral part of every project we undertake, as well as a key ceremony in the Scrum lifecycle. Agile principally stresses the need to perform periodic meetings to reflect on the functioning of the team, their processes and actions and try to improve their shortcomings, so retrospectives are essential. The team gets to look back on their work and answer three key questions: What went well? What did not go well? How can we improve?

Even if agile teams perform retrospectives as a regular part of their project lifecycle, there are a few common mistakes they may be making due to a lack of understanding, perspective or communication, and these mistakes can prevent obtaining the maximum benefits of the retrospective.

In my article for Gurock TestRail blog, I have discussed five common mistakes that we must avoid in Agile Retrospectives.

 

Click Here to Read more

Do let me know your thoughts!

Cheers

Nishi

 

Key QA and testing takeaways from the Agile manifesto

My first article for Global App Testing blog is now published at

https://www.globalapptesting.com/blog/key-qa-and-testing-takeaways-from-the-agile-manifesto

             >>>Agile testing leaves very little time for documentation. It relies on quick and innovative test case design rather than elaborate test case documents with detailed steps or results. This mirrors the values of Exploratory Testing. When executed right, it needs only lightweight planning with the focus on fluidity without comprehensive documentation or test cases. 

From a QA viewpoint, we can learn from the Agile Manifesto key goals; communication, efficiency, collaboration and flexibility. If you improve your QA team in these areas, it will have a positive effect on your QA strategy and company growth.

>>>The Manifesto for Agile Software Development forms the golden rules for all Agile teams today. It gives us four basic values, which assure Agilists a clearer mindset and success in their Agile testing.

Although these values are mostly associated with Agile development, they equally apply to all phases, roles and people within the Agile framework, including Agile testing. As we know, Agile testers’ lives are different, challenging and quite busy. They have a lot to achieve and contribute within the short Agile sprints or iterations, and are frequently faced with dilemmas about what to do and how to prioritise, add value and contribute more to the team.

The frequent nature of development in Agile teams means the testing methods used need to respond to change quickly and easily. In that way, Agile testing shares some important characteristics with exploratory testing.

In this article I examine the four values of the Agile manifesto to find the answers to an Agile tester’s dilemmas and improve their testing efforts. Read More

Please give it a read and share your thoughts!

Happy Testing!

Nishi

 

The Value of Risk-Based Testing from an Agile ViewPoint

When I first heard about risk-based testing, I interpreted it as an approach that could help devise a targeted test strategy. Back then I was working with a product-based research and development team. We were following Scrum and were perpetually working with tight deadlines. These short sprints had lots to test and deliver, in addition to the cross-environment and non-functional testing aspects.

Learning about risk-based testing gave me a new approach to our testing challenges. I believed that analyzing the product as well as each sprint for the impending risk areas and then following them through during test design and development, execution and reporting would help us in time crunches.

But before I could think about adopting this new found approach into our test planning, I had a challenge at hand: to convince my team.

In my recent article published at Gurock’s blog site , I have written about my experience on exploring risk based testing and convincing my agile team about its importance and relevance using their own sprints’ case study.

Using the analysis of a sprint’s user stories, calculating Risk Priority Number (RPN) and the Extent of Testing defined, I was able to showcase in my own team’s case study, ways our testing could benefit and better itself by following risk based approach in a simplified manner.

Risk Priority Number

To read the complete article, Click Here–> 

In the article I talk about–

  • Tackling the Agile Challenges
  • Benchmarking Risks and a Focused Approach
  • Improving Test Process and Results

Do share your thoughts on Risk Based Testing!

Cheers

Nishi

 

 

 

A simplified Agile Test Strategy for Cross Environment Testing

Cross environment testing is viewed as a tedious and repetitive task and is generally a challenge to accommodate within an agile life cycle. In my recent guest post for Gurock, I showcased my own experience in an agile release wherein we created a strategy for coverage of a number of test environments to support.

Using simple steps, discussions, base-lining and agreement within the scrum team, we created a scalable interoperability test strategy which was later supplemented with automation and other tools. In this article I have talked about-

  • Testing across OS versions
  • Supporting System versions
  • Localization- multiple language support
  • Planning and Test Strategy creation
  • Additional Ownership by testers

To read more, click here.

Give it a read and share your thoughts-

https://blog.gurock.com/agile-cross-environment-testing/

Print

Thanks

Nishi

Guest Post- “5 Ways DevOps complements Agile”

My guest post article for Gurock Software GmbH #TestRail blog is now up!!

“5 Ways DevOps complements Agile” – As an industry practitioner who has worked in agile for almost a decade now, I have always seen DevOps as a friend and an extension of agile. Using this article I have tried to put across my view on how this handshake between developers and operations personnel works in favor of bridging the gap from software creation to software delivery.- 

Please give it a read at – https://blog.gurock.com/5-ways-devops-complements-agile/

The major points I have touched upon in this article are –devops

  • A Focus on User’s Needs

  • Continuous Delivery

  • Concentrated Value Creation

  • Motivated Individuals

  • A Culture of Inclusion

 

To read more click here->

Cheers

Nishi