Is ‘testing’ holding you back? Stop being a bottleneck for software quality assurance

Why ‘testing’ might be holding back the quality of your software

Testing or Software QA, has traditionally been the last piece of the software delivery puzzle. Testing and finding bugs at the end of a release cycle was the norm.  However, fixing those defects, changing designs and redeveloping the features lead to more work done twice, more time spent on retesting and loads of regression. So, this approach meant testing held you back from your final goal of software quality assurance.

Being the last phase of the development process and mostly being stretched for time and resources, testing has been seen as a hold up for final delivery to market.

With the advent of Agile and DevOps the thought process has changed and the focus now continues to be more on software quality assurance throughout the development lifecycle. Testers today need to focus more on assuring quality than finding bugs.If testing prevents you from delivering on time and you become a bottleneck at the end of a release, you need to focus your efforts on other quality assurance activities, which may or may not be a 100% testing but are surely related to overall quality of your software.

In my article for PractiTest QA Learning Centre, I talk about how to overcome this. https://www.practitest.com/qa-learningcenter/thank-you/software-quality-assurance-bottleneck/

Training Developers how to test their code better

We rely on testers to test the software, which mostly happens post development. Even if we have a process around unit testing the code, developers generally write very basic unit level tests to touch upon the code, mostly just enough to meet the coverage criteria set for them.

If we train our developers to think beyond the basics and write more unit tests, it will exercise the code in various new ways and catch more potential defects earlier. A more exhaustive unit test suite will also reduce reliance on black box functional tests, and reduce regression loads at the end.

Also, beyond unit testing, we can train our developers to run some functional tests when executing the code before packaging and sharing for testing. For this, we can get assistance from the testers to share their basic test scenarios with the entire team.

Everyone in the team is responsible for quality, and hence everyone including developers, BA and Scrum Master can ensure that the basic test scenarios never fail and hence a basic level of quality is forever maintained.

Reviews as checkpoints

To ensure a benchmark of quality is achieved at software delivery, we must set up some quality assurance practices related to everything we do within the development lifecycle. To ensure these practices are followed, we must also enforce some process, tool or exit criteria for them. Some examples can be –

  • Every developer needs to get their code reviewed by their peer or senior developer in the team. So, for each feature or user story development task, we have a corresponding code review task, assigned to the reviewer developer and blocking an hour of his time for it.
  • The test cases that a tester creates for any feature must be reviewed by the entire team. So, testers create their tests early and share it across with the entire team. If any feedback, suggestions or changes come their way, they accommodate it even before beginning to test. But if no responses come in, it is assumed that tests are as expected and then no conflicts will arise later on how the feature was tested.
  • Testers need to be included in all requirement and design discussions. For this, we ensure that all meeting invites are sent to the entire team and testers are encouraged to focus more on activities like design reviews, requirement analysis and giving more inputs in those phases, so that the numbers of defects found, decrease over time.

By enforcing these practices, we are setting up more checkpoints along the way of our software creation rather than having a big blocked gate at the end in form of a testing phase.

Customer Focus Groups

Though companies mostly have a customer support team to respond to customer issues or production server problems, it would be beneficial to set up a core customer focus group within the development team. Including a few developers and testers along with the BA, this core focus group can keep track of all inputs that come from the customers including issues, suggestions or queries about new features. These can be great insights for the team to keep the focus on the real user’s needs and see their perspective.

 

The focus group can also:

  • Keep an eye on the production data and set up similar ones for internal tests
  • Keep a count of support tickets and try to help close them quickly
  • Monitor the servers and keep track of error messages received

At regular intervals, this focus group can publish their findings and observations in relation to the customer’s responses and help the entire development process get more aligned towards reaching maximum customer satisfaction.

Change in team’s Mindset

We need to train our testers to think beyond defects, test case counts, and coverage measures.

Focusing solely on executing tests at the end of the development phase is not the way to achieve quality and provide real value to the team. The focus should not be “finding bugs” but “assuring quality”.

For this, we must encourage testers to work in pairs with the developers on their assigned features or user stories. The team must not have a developer – tester divide. Instead, they must have a collective ownership for the success of their feature/ user story/ sprint or release.

Tool Support

To set up such software quality assurance practices, we also need the correct tool support. Here are a few features and practices to look for in any Software QA tool:

  • End to end traceability of requirements, user stories, their designs, tests and corresponding defects
  • Functionality to encourage testers to go beyond scripted tests and focus also on Exploratory Testing. This also exposes any defects earlier and hence reduces the cost of defect fixing in the long run.
  • Generate informative and professional visibility via dashboards and reports to share with the team and stakeholders. Try to share the relevant data to each stakeholder.

And most importantly, we must always select a tool which is easy to integrate within our ecosystem and hence can transmit information and work with all various tools we have set up in our development lifecycle.

Summary

If you feel testing is holding you back from right time deliveries and turning your team into a bottleneck at the end of the release, you need to focus your efforts more on quality assurance activities that are related to the overall quality of your software – and less on the actual execution of your tests. Hope the tips shared here will help out you and your team achieve the quality levels we dream of!

Thanks for reading!
Nishi

Pic Credits blog.commlabindia.com

FACTORS TO CONSIDER WHEN SELECTING THE RIGHT SOFTWARE FOR YOUR BUSINESS

Running a business in today’ tough competitive world is not everyone’s cup of tea. You need to be well ahead of your competitors in terms of marketing, services as well as technology. Being a business owner, you should always look up for software tailored for your business, which can simplify things for you, your customers or even your employees for that matter. Not only this, you should try to extract the best of possible from that software.

Many business owners are unaware of the advantages of having the right tools at hand. And those who realise it may lack the knowledge on choosing the correct software for their business. So here is a guide to such business owners about what factors they should keep in mind while choosing the right software for their business.

  • ANALYSE YOUR NEEDS

You should be clear in your mind about your needs. There are two kinds of software, one that is general to all kinds of business. For example, general accounting, and the other one which is specific to a particular kind of business. For example, a restaurant owner would need software which can manage recipe cost along with the front-of-house to back-of-house communication, or a manufacturing business may need a software which can track shipments and provide supply chain information.

  • THE COST INVOLVED

Cost is a really crucial factor in choosing a software. You have to see to it that whether you can reasonably afford to purchase new software for your business or not. And if it is a sure thing, then you should take into considerations the features that you will need both now and in the coming few years. You should not be willing to pay for bells and whistles or functions that are not required in your business. Before choosing a software, carefully analyse your needs and keep in mind not to alter your needs to fit the software.

  • BUSINESS SIZE

Maybe you find the appropriate software for your business which has all the required features, but the cost of software may not be justifiable for your business. There is no need of big mathematical calculations to see that it is a bad investment. Rather than opting for mega software in the beginning, look up for small or mid-range programs. As the time passes, keep on upgrading them as per your needs and requirements.

  • THE FEATURES PROVIDED

Many companies that make business management software often stuff the package with tiny features which increases the cost of the software. Get a good look at them, and if they are optional add-ons, try avoiding them.

What happens is, some of the features might look useful on a whole but are not required in your business. For example, consider mobile alters and reminders. If you own particular software for your business, then you will be opening it on a daily basis. There will be alters on your PC screen. Then what is the need of having reminders on your phone?

  • AFTER DELIVERY SUPPORT

No matter how good the software is, it always needs the after delivery support from the company. The company providing the software should train you and your staff in first place about how to use the software and set up the necessary networks and terminals etc. You are paying for these services and they should be available for you whenever you face any difficulty or issues with the software. Even if there is a bug or error in the software, it is the software provider’s responsibility to rectify it.

Now that you have an idea on how to choose software for your business, start looking for one. Carry out your own research and make full of trial periods before you actually buy any specific software. And lastly, take in consideration the feedback of your staff before making the final choice.

Hope these tips help you make an informed choice!

This is a guest post by Nitin Gupta, contact nitingupta2817@gmail.com. Check out more at http://www.espine.in/

 

Crafting User Stories That Agile Teams Will Love

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-

https://blog.gurock.com/crafting-user-stories-agile-teams/ 

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

 

The crucial guide to Software Testing for Project Managers

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..

https://www.practitest.com/qa-learningcenter/thank-you/software-testing-guide-project-managers/

state of mind

Do give it a read and share your thoughts!
-Nishi

 

This website is now featured in the 75 Best Software Testing blogs!

It’s a big day for me as my personal blog has been featured in the ’75 Best Software Testing Blogs’ by 🙂

Check out the complete list at — https://abstracta.us/blog/75-best-software-testing-blogs/

Elated and Excited! Please give a thumbs up and follow me for testing and agile related articles.

To follow this blog –> Add your email ID on the right side panel, and receive periodic updates with new articles and posts!

Listed in top 75 blogs

Thanks a lot!

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

 

Is Excel holding back your testing?

My guest post @PractiTest QA Learning center

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.

excel--img

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

  • Visibility within the test team
  • Configuration Management of test items
  • Test Planning and Execution
  • Test Status and Reporting

Please give it a read and share your thoughts!

Cheers!

Nishi

 

Published–Is-excel-holding-back-your-testing

 

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