I don’t exactly remember when I first came across the Project Management Triangle . But it left a huge impact on my psych as a developer.
Whenever I find myself battling to be on time (which happens quite often), the ghost of the triangle, plays scenarios in my mind. Can I push the date? Get more people? Do I really need to fix this defect?
I am not here to do a critique of the Project management Triangle . But just wondering- is there another way to be on time? be able to do more within the same constraints ?
These are our endeavours- in particular order…
We are currently using ant. We decided to move to Maven style repository and since we (or I) love everything groovy, Gradle seemed to be a natural choice. It may not be very obvious as to how would using gradle can help increase efficiency. Try upgrading spring and hibernate in ant based system where you have library files checked into source control (yuk !) or integrate cobertura with your test cases.
WIth its support for plugins and repositories,Gradle makes it right.
Caveat: Gradle doesn’t have a very good support for IDEs. My colleagues who are eclipse and IdeaJ fanboys, found that quite unsettling.
To me it didn’t matter much. I use Textpad (That needs a blog post by itself) <grin/>
We use AppDynamics to monitor our Tomcat applications in Production and QA. The information it reveals can be very eureka-ish . More than once, it proved very useful and helped us zoom into the problem area quickly enough. We used it to identify what classes are using up most memory and the method calls where most time was being spent. Glad to see it pick up traction within the team.
We have been using Groovy as our prefered scripting language for some time. Now we extended that to our automation scripts as well.Groovy is easy. But more importantly it was a natural fit into our existing technical skill set of Java. For a java developers- it takes as much as time needed to drink a cup of Java to get started with Groovy. The biggest advantage- Test engineers now have constant help at arms length.
Another switch we did on testing side was to use selenium as the automation framework. It has excellent record and play support. Has a pretty low learning curve. It runs fast. Has excellent community support. What else could you ask for ?
Simpler test cases:
Some of our test cases can do…better. I find them to have instructional guide built into them. The reason I generally hear in defense of such elaborate test cases is-”Oh we do it so anyone can run the test cases”. Well for one- you never have people off the street running your test cases. Secondly- if someone doesn’t know the product, IMHO- they have no business testing it. The idea we are adopting here is- KISS your test cases. Capture the intent. Move instructional guide elsewhere- (maybe to wiki ?)- it has no space in a test script. As a result, we hope to make the test cases lighter – easier to write and and easier to review and easier to execute.
Everyone needs a local setup. Developers always had one on their laptops (Oracle/Tomcat etc). Now testers have one too. “Oh !Why do testers have one? Shouldn’t they be using QA systems always?” Well. Not really. Granted we should be testing labeled builds and all that. But if you are writing an automation script, why wouldn’t you use a system local to your laptop rather than a remote shared system- you are really a developer at that time..
Note:We do not use this for our Controlled Testing. Just that- all testing and activity doesn’t have to happen on Control Test environment. There is plenty of scope for using local setup for non-control testing.
Automation scripts are for everyone:
Picture this. A new developer joined our team and she was working on a component which needed test data to be setup before she could use the component. The test data was not very complex, but had series of steps to be done in a very specific order with close to zero tolerance for mistakes. If you miss one step- you have to start all over again. She is new and doesnt enough about the app to do it on her own.
So this is what we did. Someone wrote an automation script- which would generate all the data for her and another script- which would clean all the data. She ran the script #1- got to the component she was working on – in like 2 minutes. If she had to do that manually- it would have taken her like 10-15 minutes i.e if she made no mistake. Another interesting side-effect of such convenience is that you tend to test more~
This to me is- when you get your bang for the buck on automation. Everyone should be using it- not just testers.
I am afraid- this post will not give you hints on how to improve efficiency in your team . Your challenges are different and so will be your solutions.
Both converge to give you a common message- you and your team need to identify whats holding you back and what you can do to help you go faster.
Good luck !