Reading Time: 2 minutes
In this post I will explain how I identify product moving parts (what changed in product) as a source for test strategy of product release.
Tools that I am using are Github and Huboard. Everybody knows github, and huboard is application that integrates with Github and creates Kanab board automatically from Github issues. The glue between Kanab and Github are Github labels. Github label assigned to the issue puts that issue in Huboard list.
What are tools if they are not used by humans. Every issue could be an issue or new feature. Their body should contain text that help me to understand what should be implemented. No help of tools if that body is poorly written.
Every huboard issue is connected with Github pull request. Pull request contains all files that are related with that issue. By investigating github pull request, I am identifying product moving parts.
As the application context is Rails application, pull request contains application and data (database migration files) changes. As rails uses MVC pattern, this helps a lot how to direct my testing. For example, if change is in view, controller or model file, I know which feature and scenarios I should test.
If change is in helper file, by searching the codebase for the changed method, I can also identify features that should be tested.
Rails has rake tasks, which are also under github control. If there is change in rake tasks, I know that some scripts should be run in order to prepare environment for the new feature (for example, populate database with static data).
What are the benefits of this ability to identify product moving parts? I do not need to run single browser automation test!
All the testing is done using my brain, eyes, hands and browser.
Browser automation tests are usually developed as part of regression tests. We often hear: “We are running our cucumber tests to be sure that nothing is broken”.
This is not good practice. This is like putting patient again and again through x rays to be sure that he does not have pneumonia. But asking patient questions about his physical conditions can give as quick answer about possible pneumonia.
Instead of putting hours of work in creating scripts for browser automation, try to organize your project to have:
- code base under git
- use kanab boards
- use branches
- learn basics how product code is organized (MVC in Rails)
- learn basic about programming language that is used (Ruby in Rails)