My first experience with usability testing was on an agile team where the product we were building was being designed with the help of an in-house usability expert. He helped design the user interface (UI) of the application and conduct usability study on the beta version of the software to determine the ease of use of the application.
Though the experience was limited in terms of the interaction we had with the user representatives and the sessions conducted, the feedback we received opened up lots of new avenues for the tester in me around the learnability, understandability and attractiveness of the application I was testing.
Usability has matured a lot over the years. It’s now an essential software characteristic in today’s web and mobile applications. In my article published at the TestRail blog, I discuss ways of performing Usability tests and developing a mindset for Usability in an agile context.
The agile methodology focuses on building in quality from the very beginning of the software lifecycle. That is why we aim to find and fix defects early on: A defect found and fixed in an earlier lifecycle phase is a multitude cheaper than the same defect at a later stage.
But how can we more easily make it possible to prevent defects from percolating deeper in the software development lifecycle by fixing them in their nascent stages?
This is the main theme of my latest article for @Gurock TestRail blog – where I explore and explain ways to foresee, analyze and thwart defects in an agile context.
An agile tester’s work life is intriguing, busy and challenging. A typical day is filled with varied activities like design discussions, test planning, strategizing for upcoming sprints, collaborating with developers on current user stories, peer reviews for teammates, test execution, working with business analysts for requirement analysis and planning automation strategies.
In my article for Gurock TestRail blog, I have explored a typical day in the life of an agile tester and how varied activities and tasks keep her engaged, busy and on her toes all the time!
Let’s sneak a peek into a day in the life of an agile tester — > You will go through the daily routine of an agile tester and will experience their complicated schedule in real time.
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.
>>>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