by admin | Mar 7, 2017 | Agile Testing, Fixed, Blog |
Writing testable user stories helps to conclude the development. Testable is one of the attributes for a User story. In agile software development, if a user story is too big (compound user story), we can split the story, create multiple shorter stories and put them in an epic. To conclude a story development, it must be tested successfully. So every user story should be testable.
Non-functional user stories are good examples for untestable. The following user story is not testable because it is not written from a testing point of view.
“As a user, I want a good user experience and usability on Homepage.”
You can rephrase the story as “Home page should comply with usability checklist” to make it testable. If a user story is testable, you can identify acceptance tests before the story is implemented.
by admin | Jan 16, 2018 | Agile Testing, Blog |
Getting Things Done The SAFe Way
Scaled Agile Framework is often abbreviated “SAFe”. The intention with this provision is a means of guiding various organizations in terms of practices defined as “agile” and “lean”.
Basically, the idea is a sort of consolidated system which aligns things like collaboration and delivery across multiple teams. This can be essential in properly facilitating APM, or Application Performance Management.
Stackify.com provides a list of these 10 critical APM features according to the site, “For developers, APM is really all about data…lots of data. But they need more than data, they need actionable insights from that data so they can quickly get to the root cause of what is causing application problems.”
The truth is, no matter how well you design and deploy any application, you’re going to have issues crop up eventually. Chalk it up to Murphy’s Law if you like. Human development is subject to human error, and those errors tend to crop up in ways that are persistently unique.
Think of it like digitally metaphysical whack-a-mole, if you will. As soon as one issue is resolved, another one pops up and you’ve got to knock it back with the APM hammer. How accurate you are will depend on the available tools you use; techniques like SAFe are increasingly sought for their success in facilitating such accuracy.
Application Of SAFe Principles
When it comes specifically to SAFe management, there are a number of ways in which this method is applied. One selection of practices is designed for organizations with one hundred or fewer individuals working on programs. The other selection of practices is designed for larger groups.
Your first step will be identifying which category your operation falls into. One of the next big steps is keeping proper records and adjusting operations accordingly. All businesses are going to have different idiosyncrasies which must be taken into account for the greatest effect.
Time is one of the chief operational variables to consider. If things haven’t gone a certain way in a certain time, it may very well be considerable to change operational tactics. Principles which underlie SAFe practices can help manage the resource of time.
Those employing SAFe will be led into taking a view of that being managed which is economic. Variability is assumed, and building is incremental as it is often based on cycles of learning. Milestones are set, and objectives accomplished. Operations are optimized, and decision-making becomes decentralized.
Better, More Dependable Performance
SAFe in conjunction with APM is designed to increase levels of positive performance as pertains to regular operations. These combined schools of thought and management provide information that is detailed, and can truly help enhance such technologically centered ventures.
Solutions like SEO (Search Engine Optimization) in marketing do a similar thing, in that they provide metrics like ROI for those employing such solutions to latch onto and base forward decisions around. Even as established as things have become, there is always some level of subjectivity silhouetting such digitally consumed pursuits.
Ultimately, what you want is an agile team that is able to encounter new variables and either work with them, around them, or despite them. The more cohesively organized your application management is, the more successfully such efforts can be pursued.
Transitioning your operation such that it has proper devotion to this task can be complicated, but SAFe principles in conjunction with APM can be a big help. If you haven’t looked into this increasingly common mode of app facilitation, it makes a lot of sense to do so. Being more organized in these matters can be key to competitiveness in the marketplace.
by admin | Jan 18, 2017 | Agile Testing, Blog |
The Agile approach for development has gained vast popularity as it supports timely, faster and high quality working software delivery that meets customer needs. Some of the published agile processes are Test driven development (TDD), Extreme programming (XP), Scrum, Adaptive software development and the likes.
There are unique factors that help choosing one framework over another. However, the standard parameters remain the same – Easy to learn, use and implement; Supporting tools and the value generated for the customer.
With Acceptance Test Driven Development (ATDD), business customer, the tester and the developer collaborate to produce testable requirements. They help the customer to clarify their needs, the developer to have an objective to code forward and the tester to plan for more than just functional testing.
Acceptance Test driven development (ATDD) offers a collaborative and simple approach where the product owners, developers and testers discuss the requirements by addressing the questions – “What is needed?” and then “How we will know we have done that?”
Understanding the requirements or stories is the most critical part of the Sprint. There is always a possibility of misunderstandings. Questions are usually asked by developers and testers on things that they are aware they do not know. This is called “known unknown”. But it is the “unknown unknown” that causes problems. And one of the simplest ways to address this is clear conversation, alignment to what the end result should look like and most importantly – an agreement on the criteria that will define the completion of the work.
The objective is to have specific answers, with examples if possible. ATDD focuses on having the acceptance tests specified up-front, before any coding takes place. This little extra bit of work helps avoid misunderstandings before writing any code, by getting all teams together.
Let us further see on the significance of ATDD.
A. You have been doing some ATDD already – In your agile scrum approach, you may be already brainstorming User stories with specific examples to validate the ‘Done’ or acceptance criteria. “Meeting the requirements” may be too generic in the sense that – developers will write code keeping in mind the quality (for easy maintainability) and testability of functionalities & testers will ensure the piece of software meets customer needs. The Sprint delivery can be optimized by designing executable test cases for the user stories, thereby defining the ‘Done’ criteria.
C. Automation and ATDD-Working with ATDD with your testing automated certainly is an icing on the cake. But you actually do not need to automate testing using sophisticated tools to see value from ATDD.
While working with a healthcare company with an objective to automate the test cycles, we were, for about 6-8 months deprived of approvals due to an Organization change happening at their end. We did not let go waste this time just waiting. Instead, our team gathered to brainstorm the user stories and distil them into executable test cases. The only tools used for this exercise were white board, markers and excel sheets. The developers were equipped as well with more clear objectives to write code matching the expected output of each user stories.
D. There are no special skill or tools required to perform ATDD –
Probably, communication is the key to perform ATDD. To implement and reap the benefits of ATDD, here is all that you need –
- Understand and Write User stories
- Extract Acceptance criteria from User stories
- Convert Acceptance criteria into executable Acceptance test cases
- Write code to match the Acceptance test cases
