Having been a tester for nearly a decade I was always very unhappy at the way test cases were written. Especially when they were written in the form of Click button X , pop up should appear click on OK and so and so page should appear.
I found it extremely painful and boring to write tests in this format, step by step detailed and extremely action focused.Unfortunately the only reason everyone would give me for writing in such format was "they should be executable by any person regardless of his knowledge of the application under test". This in itself is something I don't agree at all but that's for different post itself.
Then I started to make some changes in the way test cases were written by adding precondition for tests , data required for tests, actors who can execute the tests and so on , but even that was very painful , boring , and repetitive from a documentation perspective.
But this was only until I learn the Given/When/Then form of writing tests.I first came across this form of writing on my first agile project 4 years ago.And ever since have stuck to that pattern.
How is it different : Just the fact that you can start writing tests with a set of "Givens" provides a jump start to writing meaningful and valuable tests. So instead of writing tests in a way that describe how user will navigate to a certain page and interact with the controls to trigger a feature/functionality putting a set of Givens allows the tester to reach a certain place/point in the app and then interact with the application to be able to verify the functionality.
Why is it good : This format helps to build a very clear and focused set of precondition before a test can be executed thus making estimating effort for setup and execution very clear and apparent.Also the fact that the Givens are should be met before a test can be executed allows one to sequence logical tests together and get a better sense of coverage and completion of tests.
On a recent project a minor story had to be played where , only the field labels on a certain form were to be changed based on at least 6/7 business rules to comply with the new regulatory requirements. Since I was new to the project the BA quickly showed me where the form is and how to get to it via various menu items.That was the easy part. The hard part was to make sure that the even though only the form labels were changed and format and display based on the geographic location of the record , there were loads and loads of Givens that needed to be in place before I could actually reach that form.While sitting with BA it was very easy to see how he could get to that part of the app but when I started testing it myself by resorting to the GWT format I found that I had to satisfy 7 givens before I could execute a when condition and then verify the screen and format. By being able to identify the Givens I realized how complex a small piece of functionality was because of its dependency on other factors such as data, transactions, access controls and various permutations of status, other transactions etc. Also I was able to articulate the amount of time and effort required to test the supposedly "minor change".This is how my GWT format looked like
Given when a investor has invested in X funds
AND the funds declare a dividend
AND they are part in cash and part in form of UNITS
AND the user has the option to reinvest X percent of the cash dividends
AND the funds in which the investment is done allows for X percent of investment in fund Y
AND the reinvestment happens in the first quarter of the financial year
When a Income transaction on the fund is processed
Then X amount of dividend accrued by the investor should be automatically allocated to the fund Y and the remaining amount is displayed as 'Cash at Bank' in the balance sheet.
Interestingly there were at least 5 such GWT tests that I had to write to ensure that label changes on a given form are correct for each Test Case.
Also this format helps me easily communicate with developers while we are writing automated tests for the 'minor change'. Since the givens are already mentioned it automatically becomes a part of setup for the automated tests which can be injected / manipulated / or engineered via DB creates/updates statement or searching for correct data records or mocking data. Also as the givens are assumed the tests are focused only to verify the When and Then of the tests thus making the execution of automated tests faster in speed and smaller in size - in terms of line of code.
No comments:
Post a Comment