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