Tässä on Boris Buyer. Boriksella on verkkokauppa, joka myy vanhoja kirjoja internetissä ja joka tuottaa tasaisen tulon hänelle ja perheelleen. Talvella 2012 hän kuitenkin huomasi myynnin vähentyneen. Hän päätti soittaa muutamalle hyvälle asiakkaalleen ja tiedustella, voisiko hän jotenkin palvella heitä paremmin.
Boriksen verkkokauppa oli vanhentunut. Pystyit kyllä tilaamaan kirjoja kaupasta, mutta ainut tapa tehdä tilaus oli lähettää tilaus sähköpostitse Borisille. Hänen asiakkaansa kertoivat, että hänen kannattaisi helpottaa tilauksen tekemistä. Toiveita tuli myös uusista maksutavoista, toimitustavoista. Boris ajatteli, että hän oli häviämässä kilpailun ketterämmille kilpailijoilleen.
Tämä on lähtökohtana DEMO-projektille, joka luodaan automaattisesti jokaiseen uuteen Testlabiin – ja jonka tarkoituksena on olla esimerkki tyypillisestä pienestä ohjelmistonkehitysprojektista. Käytetty ketterä kehitysmalli on vain yksi tapa kehittää ohjelmistoja ja käyttää Testlabia.
Kuvauksessa on kuvia Testlabin käyttöliittymästä. Voit klikata kuvia nähdäksesi suuremman version sekä tekstikuvauksen.
Onneksi Borisilla on ystävä, Victor, joka omistaa web-suunnittelua tekevän yrityksen. Boris tapaa Victorin ja sopii alustavasta suunnitelmasta tehdä verkkokauppaan ostoskoritoiminnallisuus helpomman tilaamisen mahdollistamiseksi.
Victorilla hänen tiimillään sattuu olemaan tyhjää tilaa aikatauluissaan heti tammikuun 2013 alusta. Boris ja Victor sopivat, että on tarpeen saada aikaan ostoskorin perustoiminnallisuus niin pian kuin mahdollista. Ensimmäinen välietappi projektissa sisältää vain perustoiminnallisuuden itsepalveluna toimivaan ostamiseen ilman sähköpostitusta. Victorin mielestä myös maksutapavaihtoehtojen lisääminen postiennakon rinnalle voisi vaikuttaa asiakaskokemukseen. Boris ja Victor ovat yhtä mieltä siitä, että PayPal-maksutavan lisääminen on tärkeysjärjestyksessä seuraavana, jotta asiakkaat voisivat maksaa luottokortilla. Alennusten tarjoamiseksi hyville asiakkaille ja sesonkimyyntejä varten Victor ehdottaa kuponkikooditoiminnallisuuden toteuttamista verkkokauppaan. Boris pitää ideasta ja laittaa sen kolmanneksi tärkeysjärjestyksessä sekä samalla kolmanneksi etapiksi projektille.
Boris ja Victor sopivat alustavasta aikataulusta ja siällöstä projektilleen:
Etappi 1 – Ostoskorin perustoimintojen toteuttaminen verkkokauppaan
|Viikko 1||Vaatimusten määrittely ja suunnittelu|
|Viikko 2 ja 3||Toteutustehtävät ja testisuunnittelu|
|Viikko 4||Hyväksyntätestaus etapille 1|
|Viikko 5||Tuotantoasennukset ja etappi 1 asiakaskäytön alkaminen|
Etappi 2 – PayPal-maksutavan lisääminen
|Viikko 5||Vaatimusten määrittely ja suunnittelu|
|Viikko 6 ja 7||Toteutustehtävät ja testisuunnittelu|
|Viikko 8||Hyväksyntätestaus etapille 2|
|Viikko 9||Tuotantoasennukset ja etappi 2 asiakaskäytön alkaminen|
Etappi 3 – Kuponkikoodit alennuksille
|Viikko 9||Vaatimusten määrittely ja suunnittelu|
Boris ja Victor sopivat siitä, että Victor ja hänen tiiminsä tekevät alustavan suunnittelun ennen vuoden vaihdetta ja että eräs Victorin tuttava tekee käyttöliittymäsuunnittelun viikon 1 loppuun mennessä.
Victor suosittelee Borikselle, että on järkevää dokumentoida vaatimukset, testit sekä niihin liittyvät tiedot kirjallisesti. Tämä tekee jatkosta paljon helpompaa, erityisesti tulevien projektien suunnittelusta. He päättävät ottaa Meliora Testlabin käyttöön projektissa.
Seuraava kaavio kuvaa yllä mainitun projektin aikataulun. Yläosassa on projektin päävaiheet ja alaosassa on aikataulutettu projektin vaiheiden tuotokset. Aikataulu on jaettu viikkotasolle ja sinipunainen pallo aikajanalla kuvaa demo-projektin datan “tämänhetkistä” tilaa.
Victorin kehitystiimi ja vastuut on jaettu seuraavasti:
Victor P. Owner
Tiimin ulkopuolisia asiantuntijoita ovat vielä:
Victorin tiimi käyttää ketteriä menetelmiä ja on tottunut mallintamaan järjestelmän vaatimuksia käyttäjätarinoina. Tiimi päättää kirjata projektin toiminnalliset vaatimukset käyttäjätarinoina. Muut vaatimukset kirjataan vapaamuotoisina vaatimuksina.
Vaatimusten määrittely, viikko 1: 1.1.2013 – 4.1.2013
Victor pitää Boriksen ja tiimin kanssa suunnittelupalaverin, jossa käydään läpi ostoskorin toiminnallisuudet. Victor ehdottaa Borisille, että hän kirjaa vaatimukset Testlabiin ja pyytää Borista hyväksymään ne myöhemmin.
Victor aloittaa työskentelyn.
starts working. He knows, that all features planned to be implemented in the first milestone will act as a basis for all further work in Boris’ web store. This way, he decides to create all assets of the first milestone without targeting them explicitly to the first milestone. He goes on, and adds a new milestone Milestone 1 to the project and configures it to inherit all [Non-targeted] assets.
He brings in his expertise on web application design and decides to leave the actual Cart features to later time and start on generic security and usability related requirements. He wants the requirements to be easily tracked later on in the hierarchy and by their identifier so he creates two folders “SEC – Security” and “U – Usability“ to his project. When a requirement is specified as a Folder it means that the requirement just groups sub requirements below it. Victor goes on and adds the needed security and usability related requirements to these folders.
As said, the actual functionality of the Shopping Card is decided to be modeled as agile user stories. Victor decides to create user stories to a hierarchy by the actor. He adds some folder classed requirements as
The sub folder named by the actor will hold the actual user stories for each actor. Victor goes on and adds the user stories to each folder. US1 will hold the user stories of the Customer meaning the user who is shopping in Boris’ online book store. US2 will hold the user stories of the system – in this case the Web store. US3 will hold the user stories of the Seller meaning Boris. Victor documents the user stories gathered earlier to these folders.
When Victor is happy with the requirements and user stories he goes through them once more. He prints out some reports, takes his work home and has look through the requirements before telling Boris to approve them. Victor thinks the requirements are now good enough, assigns requirements to Boris and marks the them as ready for review.
To make sure the team and the buyer are on the same page it was agreed that Boris will review and approve the documented requirements. Boris goes on and finds that Victor has assigned the documented requirements to Boris for review. Boris reads through the requirements, finds the requirements as adequate and approves them as ready. This tells the team that the requirements have been approved by the buyer and the design can go on.
Liana takes on the challenge and starts to design the test cases which will verify the requirements Victor and Boris have planned. First, she creates a proper test category structure for the test cases to make the grouping of test cases easier. She decides to follow the similar actor based category structure as in requirements for all functional tests and add some folders for security and usability related test cases. Liana also informs Pedro to reserve some time for test case review at the end of the week as Liana plans to have the test cases ready as soon as possible.
Dean tells Liana that he is planning to implement some automated integration tests to his build. The automated integration tests are periodically run with Jenkins Continuous Integration server and will test some of the most important technical aspects of the system. For this reason Liana adds an additional test category “Integration tests”. The final test category structure created is as follows:
Liana reads through the requirements and goes through the user interface layouts provided by the user interface designer and starts to type in test cases. With the help of Dean she describes the needed security test cases to fulfill the security requirements defined. Liana knows that the usability will be reviewed by an external expert. For this reason for usability, she just adds a stub test case for usability defined as just to ensure that the report the expert will deliver gives a green light for the cart’s usability. Liana knows that it is not always necessary to design as detailed steps for test cases as possible – just as detailed as needed to ensure that the requirements are verified.
As agreed Dean adds some automated integration test cases to the project. He adds them to the proper category and defines them with a mapping to a JUnit test class method. This way the results of these test cases will get automatically mapped to the JUnit results pushed by the build server Dean is using. As Dean adds the test cases he describes them on the level which will help him when he actually programs the automated tests to his build.
When Liana is happy with her test cases she goes thru them once more. She additionally ensures that all the test cases are bound correctly to the requirements which the test cases are designed to verify. For this Liana just drags and drops the test cases on the requirements for the binding.
Finally Liana assigns test cases to Pedro for review. At the end of the week Pedro logs in to Testlab and as agreed goes through the test cases and reviews and approves them. He uses the Requirements-, Test Case Design- and Test Coverage -sections to see if the test cases are detailed enough to cover and verify Boris’ requirements for the Shopping Cart. Pedro likes what he sees and as he goes thru the requirements he edits them and marks them as Covered. This tells the team that the test cases have been reviewed and Pedro thinks that the test cases are good enough to verify the requirements for Boris’ Shopping Cart.
Pedro knows that Dean has been working day and night to get the first milestone done. He knows that Dean would like that Liana would start the testing on the features already testable as soon as possible. He goes to work and starts thinking of sets of test cases that would be run as a test runs in this milestone.
Pedro knows that it’s possible to add the needed test runs to Testlab directly by using his personal work set in execution planning. Then again, he knows that he probably should add some repeatable test sets to the system as the project will span multiple milestones which will be tested fully as they are finished. He ponders a bit and ends up adding a “Production deployment tests” titled set of tests which he thinks should list the minimum set of test cases always run to a new version before it should be accepted to be installed to production environment.
Pedro wants to easily find the actual acceptance test sets for each milestone so he goes on and adds a new test set category “Acceptance tests“. To this category he copies the already created production deployment tests as “Milestone 1 Acceptance tests” and adds the few missing test cases to it which are not contained in the original test set, for example he knows that “Validate accessibility” test case is not run for every version because they have agreed for the Usability expert to deliver the usability report for only the first version.
Pedro speaks with Dean and gets informed about the functions Dean thinks will be testable by end of the week. He knows that Liana is also able to pick the test cases to be executed herself but chooses to help Liana in her efforts by adding test run “Milestone 1 Sprint 1 tests” for her to test the Dean’s progress with. Pedro set the starting date for the test run for Jan 11 and expects the tests be run for next monday and assigns the test run to Liana.
Pedro also adds two additional test runs for Milestone 1’s acceptance tests and installation tests. The first to contain all test cases that should pass for the version for it to be accepted as working and the latter one for test cases that should be run to verify that the version works correctly in production environment after the installation.
Dean is eager to know if the functionality he has already implemented works at all. Liana gets notified via Testlab that she has a test run assigned to her to be run. She opens up the test run in Testlab, selects all tests in it and starts testing.
For few first test cases everything seems to be working fine and Liana is impressed on the work Dean has done. She knows though that as this is the very first test run run against the Cart she expects some issues to be found in it. And so it is that the third time is the charm and the “Remove items from cart” test case does not work as expected. A confirmation dialog is missing when she removes all items for a specific product from the Shopping Cart. Liana marks the test case step and the test case as failed and adds an issue “DEMO-1 – Removing all items for a product does not show confirmation dialog” for Dean to resolve.
Liana goes on runs all the remaining test cases and finds three more issues with failing test cases. She adds the issues and assigns them to Dean.
Dean knows that the first milestone version should be in acceptance testing by the week four. He gets notifications from Testlab that Liana has found some issues in her first tests. Dean goes thru the issues and adds some comments to them when applicable. He goes on and fixes the issues, adds comments and marks the issues as resolved. He knows that the test cases for the issues should be retested before the acceptance tests so he assigns the issues back to Liana for closing.
Liana gets informed that the issues should now be fixed. She adds a new test run “Milestone 1 Sprint 1 retest” for test cases that failed in previous run and starts testing. While she is testing she closes the issues found in the previous run. She is satisfied to find that the issues are now resolved.
As planned Dean has implemented some automated integration tests to his build to test the essentials under the hood. He has Jenkins Continuous Integration server set up to build the application nightly and to push the results to Testlab.
Pedro and Dean are happy to see that the automated tests work as expected in the System test environment and report all green in Testlab.
Liana has a talk with Dean and Pedro and gets informed that the implementation is nicely in schedule and the acceptance testing can be run as planned. Acceptance tests are run to verify that the requirements are covered and the planned functionality works as expected before installing.
Liana starts testing. The acceptance test run has all the test cases needed to pass for the first milestone version. She is glad to find that only one test case has some issues: An event log file that should be written to server’s file system was not found. She is a bit baffled as this file did exist previously as expected and adds a comment about the fact with the issue. She assigns the issue to Dean for resolving.
Dean reacts quickly and notices that the server has some file permission problems with the directory where the application is trying to write the event log file to. He quickly fixes the issue, marks the issue as resolved and adds a comment to the issue. As it was only a server specific issue Liana decides that she re-tests and closes this issue in the production after the installation.
The team meets up to discuss whether the version in testing environment is acceptable to production. Pedro presents the coverage of the Milestone 1 version and everything shows up green expect the traceability requirement regarding the event log file. As Liana explains in the comment of the issue the issue is environment specific and should not show up in the production environment. In addition to this the team goes thru the issues with issue list report and concludes that everything seems to be ok for production installation.
Victor meets up with Boris and reports that all should be green for the deployment of the first milestone version of the Shopping Cart. They agree that Wednesday the 30th of January is a good day for a small downtime in Boris’ web store. They plan to take the version to production and Liana is on standby to run the test cases scheduled after Dean reports back that installation has succeeded.
On the 30th Dean goes to work and sets up a maintenance break page for Boris’ web store. The maintenance break page is set up in a way that Liana has access to the production server but customers from the outside internet do not. Dean installs the Shopping Cart application to the servers and tells Liana to start testing.
Liana runs the test cases in “Milestone 1 installation tests” test run and is happy to find out that the Shopping Cart works as expected! Victor reports back to Boris and tells the good news. They decide to take down the maintenance break page and open up the brand new enhanced web store to the public!
For the project to go on as smoothly as possible Victor knows to start planning the next version of the Shopping Cart as soon as possible. He kicks of the design of the PayPal enabled Cart at the same time with the finishing of the previous milestone.
Victor gives a call to the User Interface Designer and makes sure that he is able to deliver the updated UI design at the end of week five at the latest so that the test case design and implementation can proceed as planned.
Victor knows that the next version is quite simple. He talks with Boris and gathers up the requirements for the PayPal payment option. Victor documents the findings and adds a couple of new user stories: “US1.5 – Choose to pay with PayPal” and “US2.3 – Get payments from PayPal“. He adds a new milestone Milestone 2 [PP] to the project and configures it to inherit all assets of the previous milestone.
Then Victor goes on and goes thru all the existing requirements to see if they need any refinement because of the new added payment option. He updates “US1.4 – Checkout and place an order” user story which creates a new version to the Testlab project for the user story. Finally Victor assigns the created and updated user stories to Boris and marks them ready for review and marks the user stories as not covered.
Boris logs in to Testlab and gets notified about requirements needing some work. He reads thru the user stories Victor has asked him to review, likes what he sees and approves the requirements as ready.
Liana talks with Dean and they go thru the changes in user stories. She finds the relevant requirements from the project easily by looking which requirements and user stories are currently marked as not covered. They agree that the changes in the application are quite small so they agree that it’s probably enough to test the implementation of Milestone 2 once and for all in acceptance testing phase. Dean is confident in his skills and promises Liana to deliver a working version in one go.
Liana knows that she must go thru the current test plan and make sure the test cases cover the new and updated user stories. She does this and ends up adding a new test case “Pay with PayPal” and updating a few: “Enter shipping address“, “List and view confirmed orders“, “Verify event log” and “Submit an order“. She assigns the test cases to Pedro for review so that she knows the test cases are given an another look before testing.
Dean knows that PayPal integration adds some important fields to his data model in the application. He goes through his automated tests and updates “Submit an order” test case to ensure it is still up to date with the PayPal related changes.
Pedro‘s e-mail inbox pings and he gets notified about the test cases to be reviewed. Luckily he has spare time in his hands so he goes on to read through the updated test cases and the requirements verified by them. He approves the test cases as ready and marks the requirements as covered.
Pedro knows about Liana’s and Dean’s plan to test the changes in one go at acceptance testing. He starts to think about the test runs needed for the testing and adds the “Milestone 2 Acceptance tests” test set with a list of test cases to verify that the Shopping Cart still works with the PayPal payment option included.
By using the test set added Pedro adds a new test run “Milestone 2 acceptance run“, assigns it to Liana due to be run between 18th and 20th of February.
Dean, Pedro and Liana meet up and agree that everything is in place for acceptance testing. On Monday the 18th Liana starts testing. She works hard for few days and finds that some issues are present in the application. Liana adds her findings to Testlab as issues and assigns them to Dean. The handling of shipping address for the order has some regression compared to the previous version and PayPal paid orders payment identifiers are missing from the Boris’ order management view.
Dean gets notified about new issues. He adds some comments to the issues, fixes them and marks the issues as resolved. Pedro gets informed about issues in acceptance. He reports this to Victor and schedules a re-run for the test cases related to the issues to be run on Wednesday 27th of February.
Third milestone is a next version of Shopping Cart with discount related features including handling of coupons.
At the same time when the previous second milestone version is in it’s finishing stage Victor thinks ahead and starts to plan user stories for the third milestone. He adds the third Milestone 3 [C] milestone to the project and, three new requirements: “US1.6 – Enter a coupon code for a discount“, “US2.5 – Validate coupons” and “US3.6 – Add new coupons“.
The first milestone with basic Shopping Cart features is happily in production and customers can now enjoy themselves more shopping the books Boris is selling. The second version with PayPal enabled payments had some issues which are fixed and a re-test test run is scheduled for it but it is not yet tested. The third milestone with coupons has been started with requirement planning.
You can and should log on to a Demo-project in your Testlab. The data included in this project represents the assets and actions executed in the above description and is left in the state of 25th of February 2013.
This section contains some pointers on what to look for in the Testlab project. We recommend that you log on to the Demo project in your Testlab and follow the steps explained here to help you familiarize yourself to the concepts in Testlab.
For a single test run
For a single test run the status of the testing is seen by going to Test Runs view and selecting a test run. The pane below lists all test cases run in the test run, results for them and some additional details. You can expand each row to show a result card of an individual test case. To drill down into issues found for each test case you can click the value on the “Issues added” column.
Current status of requirements
As said, the project is in finishing stages of Milestone two which has some issues with it, milestone one is accepted and successfully installed and third milestone has been just started with requirement planning. To get an understanding of the project’s status is probably easiest achieved by looking at the Test Coverage view.
For a milestone
Go to Test Coverage view and select a milestone. By default, the coverage status is shown against all current requirements in the project’s up-to-date specification. For milestones “in the past” this is probably not what you want and you’d prefer a view in the past milestone which includes only the test cases intended to be run or have results for. You can get this by checking off the “All requirements” control. To go further please go on and select the “Milestone 2” from the coverage controls to get a glance at the status of the second milestone.
For a version
Go to Test Coverage view and select a version. A version here is a technical software version installed and is tracked as a typical software version number such as 1.1. As explained for Milestones above similarly with versions, you can control if you’d prefer to report the coverage against all requirements in your current specification or against only the requirements which relate to your version through executed test cases.
If you’d prefer to report the progress of your testing for a time period the easiest way is to generate a fitting report. Testlab provides you a set of reports out-of-box including progress reports for covered requirements, test case results and issues. Try it out and generate a progress report for project’s requirements and user stories by selecting Reports > Requirements > Testing progress for requirements from Testlab’s menu bar. You should get a report formatted as a PDF document about how the requirements and user stories of the project have been covered in testing during the time period.
The same kind of progress report can be generated for test cases of the project by selecting Reports > Test cases > Testing progress for test cases and entering similar report parameters as earlier. The report shows you how the results of test cases has been developing during a time period. Try it out with issues too by selecting Reports > Issues > Issues’ development.
Remember – there is a number of configurable report templates available out-of-box for your use. You can find descriptions of different report types in Testlab’s help manual by reading the Reporting chapter.
You can use and setup your dashboard with widgets you prefer to keep you up to date with your project. Try it out by configuring your dashboard and dragging and dropping the “Current issues” widget to some slot. The widget you dropped shows the current issues in the project – in the case of Shopping Cart project the few resolved issues still to be re-tested and closed for Milestone 2. The “Project time line” widget is also handy for a quick glance on recent events in your project.
Thank you for your attention! It should be noted that the Shopping Cart project chosen and described above is just one kind of quality related project you can manage with Testlab. The practices and methodologies used are picked to suit a small and agile project with a distributed team. If you for example think that reviewing is time consuming and unnecessary you can apply a simpler workflow for you project.