Gherkin is a language used to write acceptance tests. BA's use Gherkin to specify how they want the system to behave in certain scenarios... It’s a simple language. There are 10 key words (e.g. Given, When, Then). Because it’s a simple language, it’s understandable by the business. As well as being understandable by the business, Gherkin can be understood by an automation tool called Cucumber. That means Cucumber can interpret Gherkin and use it to drive automated tests. This links BA requirements to automated tests.
How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.
Before an organization releases a new piece of software or web feature to all of its customers or the general public, it will generally offer a limited audience a chance to test drive the feature and offer their feedback. This is generally known as a Beta launch...
This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.
We BA's are occasionally asked, "What do you do?" I try to make a joke out of this innocent question by replying, "Well, what would YOU do with English and writing degrees? I'm a Business Analyst of course." People don’t laugh.
Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.
For most businesses and organisations, if IT stops, the business stops. Whenever a company turns on a new production line, opens a new retail store, launches a new product or provides a new service, there is invariably a new or modified IT system behind it. Going live is the culmination of time, effort, resources and finance. A problem-free IT system is the “acid test” of significant, often crucial investment.
Whilst the technical testing of IT systems is a highly professional and exhaustive process, testing of business functionality is an entirely different proposition. Does the system deliver the business functions that are required – does it follow the company’s business rules – does it support a government department’s obligations - does it cope with exceptions? The people who have to make these decisions – to accept or reject the new system – are the business users. It is therefore critical to get the business user involved in testing and not rely only on the technicians. In this paper we explore the rationale behind User Acceptance Testing (UAT), why it is so important, and how best to go about it.
Author: Jan Kusiak
Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics? Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.
brought to you by enabling practitioners & organizations to achieve their goals using: