Guest Speaker at the first ever uTest Meetup @Bangalore!

Nishi Grover Garg1 Comment

uTest is the most wonderful community of testers from across the globe where passionate testers connect, network, discuss, learn and of course – Test!

uTest recently initiated a drive to have meetups across the globe and a result of that was the first ever uMeet organised at Bangalore. It was a fun and wonderful event where utesters shared their stories and journeys with uTest. I too got a chance to speak on my favorite topic of Agile testing and discussing practical agile testing challenges.

Thanks a lot to the organiser Yamini and her friends who chipped in with the setup. It was great meeting the people we know in the community, some of whom are really rising the ranks in uTest. I sure hope to continue my journey with uTest and now Applause.com writing for the forums and also doing some happy testing!

Here’s a sneak peak for you!

This slideshow requires JavaScript.

Cheers!

Nishi

 

11th ATA Meetup – Feb’17 @Epsilon, Bangalore

Nishi Grover GargLeave a comment

ATA strives to spread knowledge about agile testing and aims to create and nurture a community of agile testers by organising events like conferences, contests and meetups. ATA meetups are free open events which bring testers together for thought provoking talks, discussions and networking opportunities to passionate testers in the area.

18th February 2017 was a great day with the 11th ATA meetup organised in Bangalore courtesy the wonderful team at Epsilon. ATA community got together at the Epsilon venue for some good discussions and talks, one of them being mine!- on the topic “Agile vs Traditional Testing”. Other speakers who graced the occasion were Shanthala and her team from Epsilon talking about “Campaign Testing” and Amit Vyas from Moolya talking about “Client side Performance Testing”.

Here are some pictures from the day-

Stay updated at www.agiletestingalliance.org for upcoming meetups and events. We are looking for volunteers and organisers for our next events, and also reach me in case you have ideas to present on our next meetup!

This slideshow requires JavaScript.

Cheers,

Nishi

Awesome day at NFTCon 2016- Great Event and being Awarded by UNICOM!

Nishi Grover Garg1 Comment

I had the chance to partner with UNICOM recently to help plan out a new event called NFTCon 2016 (Bangalore)- i.e.Non Functional Testing Conference 2016.

It was a niche idea for a one-of-its kind event catering specifically to non-functional testing, with main focus on Performance , Security & Usability testing along with Accessibility and Reliability testing. It was designed to be a 2-day event with 2 tracks on each day, with many great speakers, some wonderful round table talks and a zealous audience.

I was also felicitated by the nice team at UNICOM for my contribution to the event and chairing one of the tracks. It was such a nice gesture and kind words, I thank the team for their efforts and I look forward to our next association pretty soon! 🙂

Here is a peek into the event —

This slideshow requires JavaScript.

Cheers

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/

A day well spent at the STeP-IN Summit 2016, Bangalore

Nishi Grover GargLeave a comment

I recently received an invite to the prestigious event STeP-IN Summit 2016, since my training company was one of the Gold sponsors of the event. It is an annual event organized in Bangalore by the STeP-IN Forum, and the workshops also extended to the cities of Hyderabad and Pune where the forum has its local chapters.

The event was a full-house with 400 delegates, 35 speakers and meet and greet sessions. Though I happened to attend only one day of the 2-day event, it was a great experience listening to some amazing keynote speakers and talks. One talk by Mr. Wolfgang Platz from Tricentis on ‘Ninja or Samurai? The Art of War and the Future of Testing‘ was an definitely an eye opener into the future of our industry. The event also saw some excited participants from across the country for the Automation Contest where the best minds came together to live up to the challenge.

I also had a chance to attend a pre-conference workshop on Exploratory Testing by Ajay Balamurugadas, which was a good hands-on session on practical aspects of testing.

This slideshow requires JavaScript.

ISTQB Certification Camp for Corporate Team

Nishi Grover GargLeave a comment

One of the renowned corporates recently invited us to conduct a ISTQB certifcation camp at their site, where I led and trained a team with the most interesting mix of candidates having experience range from 2 years to 11 years ! Most of the candidates were domain experts shifted into testing teams , were leading testing efforts in their teams and all of them had the urge to take their learnings from our training back to their teams and project’s context.

We had some great conversations not only about the course content , various test design techniques and tools, but also about agile and the struggles they had with scrum and the measures to improve upon them.

The course delivery went great and I received impeccable feedback from the candidates! I wish them the best of luck for their certification attempt as well as their future endeavours!

WP_20160615_010WP_20160615_011

Advanced Level Workshops with industry leaders

Nishi Grover GargLeave a comment

My association with Verity Trainings recently led me to assist on and experience some great advanced level testing and ISTQB workshops by industry leaders! A great corporate team in Bangalore had invited experienced trainers as the likes of Mr Tarun Banga for their workshop on ISTQB Advanced Level Test Analyst which I happened to assist on as a co-trainer. It was an awesome experience and great learnings came from the interaction with a leader in trainings domain as well as the interaction with the team of candidates, having some proactive discussions, hands-on exercises and fun with learning environment.

 

Another great experience was hosting some hands-on public workshops on ISTQB Advanced test levels with Mr. Gaurav Pandey , where we met some excellent, self-driven individuals with keen sense of learning and quest for excellence in their careers.

With these interactions, I experienced that every trainer has their own style of delivery and conduct , even with similar content and exercises.And every candidate is bound to have their own experience with the training depending upon their agenda , quest and initiative!

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!