All about software testing , agile , DevOps, certifications , events and more from the eyes of Nishi
Author: Nishi Grover Garg
Principal Consultant Trainer, President Bangalore Chapter ATA
Industry Experience - Nishi is a consulting Testing and Agile trainer with 9+ years of industry experience working in Agile environment and has hands-on experience in all stages of software testing life cycle from White box, Black box, Automation testing to Regression and Usability testing. She has had the role of mentoring and training the new joiners to her team, and conducting in-house Induction training programs and Knowledge-sharing sessions.
She is CP-AAT, CP-SAT, CP-DOF, CP-MAT, Agile Scrum Master ASM and ISTQB certified (Foundation and Advanced Test Analyst & Test Manager)and likes to keep updating her skill periodically.
Speaker and Trainer - She is a consulting Agile and Software Testing trainer and also has been a speaker at numerous testing events and conferences. She has been deeply appreciated for her sessions at renowned conferences by UNICOM and ATA in Bangalore. She has also been awarded for chairing UNICOM’s NFT-Con Event in Dec 2016.
Freelance writer – numerous articles published at forums like www.agileconnection.com , www.stickyminds.com She is very active in the industry and also has her own blog www.testwithnishi.com where she writes about the latest topics in Agile and Testing domains.
A popular term you will come across when working in agile is the “user story.” For the uninitiated, a user story is a technique of expressing software requirements in a specific format, usually:
As a < role of user >, I want to < perform an action >, so that < goal of user >
This adds more detail and description, and it’s sure to include the real need of the user when expressing the requirements.
For agile teams, user stories are a typical way to begin a conversation about a feature. But issues arise when we stop adding more beyond the one-line user story format. Most agile teams are crippled by incomplete, ambiguous and vague user stories that lack depth and details.
In my experience, there are some ways we can ensure that the user stories we craft are usable and valuable in all aspects. In my latest article for Gurock TestRail Blog, I talk about strategies to craft meaningful, understandable and valuable user stories for your agile teams.
We discuss INVEST Principle of User Stories, 3Cs of a User Story and how to learn from Experience of past sprints to improve your user stories. Read the full article here-
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.
Being a Project manager you often need to take on new challenges and create guidelines for projects in a field you are not always familiar with.
You might have some experience working with a team of software developers, which gives you insight into the relevant testing disciplines. Or you may have directly come in as a project manager and need to begin understanding the process from scratch. Whatever the case may be, we are sure you already have enough on your plate. That is why I have gathered a few basic guidelines – both technical and methodological – to help you succeed in your new assignment as a test project leader!
My guest post for PractiTest is now up on the QA Learning Centre-
Dedicated to all PMs – here I discuss the Software Testing 101 making this a guide to all PMs to all things crucial in test process management. Read More..
>>>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.
As testers, we all worked with Excel at some point in our career. If you are using
excel now this article is for you 🙂 Excel is used as test management, documentation
and reporting tool by many test teams. At early stages, most teams rely on excel
spreadsheets for planning and documenting tests, as well as reporting test
results. As teams grow, sharing information using excel sheets becomes problematic.
What used to be easy and intuitive, becomes very challenging. Encountering
difficult work scenarios like the below, becomes a day-to-day reality:
The simple task of figuring out which excel has the test cases you need to run, takes longer and longer.
Gathering the status of the testing tasks and your project can only be done by going to each desk one by one and asking them.
A tester mistakenly spent 6 hours running wrong tests in the wrong environment because of an incorrect excel sheet which was not the updated copy.
Tester’s routinely lose their work or test results because of saving/ overwriting or losing their excel sheets.
Most test activities are not being documented or accounted for because writing tests is considered a luxury.
If one or more of these scenarios sound familiar to you, you are being held back in
your testing efforts by excel!
In my latest guest post for PractiTest, I have written about how excel can be a roadblock instead of a useful tool for your testing. To read the complete article, click here—->
In here I talk about issues related with use of excel in relation to
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.
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-
Want to Outsource your testing? Here are my “5 tips to manage your outsourced testing”
I have begun collaborating with PractiTest and with the help of Rachel, my article has now been published @PractiTest Learning Center.
In this article I have discussed about the practical risks for teams that outsource their testing efforts. I have brought forward 5 key tips and tricks to manage their outsourced software testing along with team and people issues as follows:
Thanks to the fantastic organisation and management of our team and the amazing enthusiasm of the attending delegates, Selenium Summit 2018 organised by ATA at Pune on 22nd March 2018 was a huge success! All keynote talks were greatly appreciated and the hands-on workshops also were received well.
My workshop on “Selenium and Cucumber integration for an extended BDD Framework” received overwhelming response from the audience with more than a full house! 🙂
Here is a glimpse into the event and a sneak peek into the workshop too-
Thanks everyone who made this event a grand success!