‘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

Optimize Your Hardening Sprint for a Quality Advantage

A hardening sprint is an additional sprint that some teams run to stabilize the code and ensure that everything is ready just before release. Agile teams vary in their opinions on using hardening sprints in Scrum, but if your team does agree on having one before your release, there may be a lot to be done and varied expectations from the product owner, testers and developers. It may also lead to other work being delayed, leading to accumulation of technical debt.

In my article for Gurock TestRail Blog, I have discussed some tips on optimising the hardening sprint and achieving the maximum quality before release.

I talk in detail about some main points to focus on–

  • Plan Ahead
  • Perform End-to-End Testing
  • Perform Non-Functional Testing
  • Perform Tests on Other Platforms and Languages
  • Reduce Lower Priority Defect Counts
  • Use your sprint Wisely

Read the full article here — > https://blog.gurock.com/optimize-hardening-sprint/

Please share your thoughts!

Happy Testing!

Nishi

Using a Combination of Scripted, Automated and Exploratory Testing for Optimum QA Coverage

Most test teams today are struggling to find better ways to handle their testing. With the advent of Agile in our software development processes, teams are perennially under pressure to provide faster releases without lowering their standards of quality. This, in turn, adds load on the in-house test teams to ensure finding more and crucial issues and to prevent defect leakage. For this reason, testers look at strategies and practices that can help them achieve their goals and add more value to the product’s quality.

In my opinion as a hands-on agile tester, there is no single silver bullet to quality, but a combination of different types and approaches to testing that can help us get closer to our quality goals. Test teams need to strategize and plan the usage of a combination of scripted tests, automated tests as well as exploratory tests for achieving an optimum coverage and best quality software.

Here is my latest article for PractiTest QA Learning Centre where I discuss the need to have a combination of scripted, automated as well as exploratory tests for an optimum QA coverage–

https://www.practitest.com/qa-learningcenter/thank-you/exploratory-testing-optimum-qa-coverage/ 

Scripted Tests

When we look at the typical test approach, it begins with test scripting and designing tests as per software functionality. These are created using requirement analysis and test design techniques and also using common sense and skills by our skilled testers. These scripted tests form the starting point of testing a new feature, change or addition in the software.

Automated Testing

In addition to running the scripted tests manually, testers also rely on automated tests. These tests are scripted using various test automation tools and test automation, i.e. ability to write these automated test scripts is, thus, a much-wanted skill nowadays for all test professionals. The ability to run some tests using automated scripts helps repeatability and saves a lot of time and effort on part of the test teams. But most importantly, by automating the drudgery away, it saves the tester from repeated manual laborious tests and frees up their time for more creative thinking and exploration around the application.

Exploratory Testing

Exploration of software is basically looking at the feature/functionality/change and overall behavior from a learning as well as a critical standpoint. Exploratory Testing is a crucial aspect of software testing, which almost every tester performs knowingly or subconsciously.

Cem Kaner coined the term Exploratory Testing in his book “Testing Computer Software” and described it as:

“Simultaneous test design, test execution and learning with an emphasis on learning”

https://www.practitest.com/qa-learningcenter/thank-you/exploratory-testing-optimum-qa-coverage/ 

Read More »

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

 

Exploratory Testing using “Tours”

My latest article for stickyminds.com “https://www.stickyminds.com/article/using-tours-structure-your-exploratory-testing” talks about using TOURS to enhance the exploratory tests you perform and add more structure and direction to them.

Here is my experience report on using Tours in my testing project-

WHAT ARE TOURS —

In testing, a tour is an exploration of a product that is organized around a theme. Tours bring structure and direction to exploration sessions, so they can be used as a fundamental tool for exploratory testing. They’re excellent for surfacing a collection of ideas that you can then further explore in depth one at a time, and they help you become more familiar with a product—leading to better testing.

I had just started working with a new product, a web-based platform that was a fairly complex system with a large number of components, each with numerous features. Going into each component and inside every feature would take too much time; I needed a quick, broad overview and some feedback points I could share as queries or defects with my team.

I realized my exploration of the application would need some structure around it. Using test sessions and predefined charters, I could explore set areas and come back with relevant observations—I had discovered tours.

Cem Kaner describes tours as an exploration of a product that is organized around a theme. Tours help bring structure and a definite direction to exploration sessions, so they can be used as a fundamental tool for exploratory testing.

Tours are excellent for surfacing a collection of ideas that you can then further explore in depth one at a time. Tours testing provides a structure to the tester on the way they go about exploring the system, so they can have a particular focus on each part and not overlook a component. The structure is combined with a theme of the tour, which provides a base for the kind of questions to ask and the type of observations that need to be made.

In the course of conducting a tour, testers can find bugs, raise questions, uncover interesting aspects and features of the software, and create models, all done on the basis of the theme of the tour being performed.

Let’s discuss some common types of tours that are useful for testers and look at some examples.

Testing Tours

Read More »