There is something professional consultants may not want you to know:
You don’t need to make major changes to your development processes in order to gain many of the benefits from Agile principles.
If you take the time to truly understand Agile (and not only repeat the Pros & Cons circling around the web), you’ll appreciate the fact that Agile is not a methodology but an approach to software development that can be applied to every methodology. Sure, methodologies such as SCRUM and XP were designed to make specific use of Agile principles, but this doesn’t mean you need to work this way in order to gain all or most of the benefits of Agile.
Some work Agile without even noticing it
A couple of months ago we talked to a customer who told us they wanted to work using Agile principles but had not had the time yet to implement SCRUM in their organization. The team’s manager mentioned that a SCRUM consultant had come to talk to them about implementing Agile, but after further review he decided it would be better to wait until their current release was out the door, within the next 6 to 9 months, to make all the necessary process changes.
This manager, being so impressed with what he heard, asked the team to make small changes and start implementing some of the ideas the consultant had suggested. And so, the team started having short 15 to 20 minute update meetings each morning over coffee and bagels.
Instead of having each programmer work on long tasks that could take between 6 to 8 weeks to complete, they started organizing tasks for shorter periods and worked in task teams of 2 or 3 programmers.
Another thing they did was to get the testers to work earlier and more closely with the developers, beginning during the coding phase itself, Testers would perform preliminary tests on the unfinished product and also give programmers ideas on how they could improve their Unit and Integration tests. As part of this process, programmers also “learned” how to run part of the manual test cases themselves before committing their changes as part of their “internal sanity.”
Finally, the manager asked the whole team to schedule a formal meeting with Product Marketing at the end of each month where they would demo the progress of the features. During these meetings Marketing would also provide feedback that could still be implemented for the current version’s development without delaying the release.
The manager told us that since they started working this way the productivity and the general working environment in the team improved greatly, and that he was really looking forward to implementing SCRUM in the team.
What he had not understood was that, without making any revolutionary changes to the way they work, they were already implementing an important number of Agile practices and experiencing their benefits.
The Road of Small Changes and Improvements
The story of this manager is a great example of how Agile can be implemented using small changes to your overall process. There is no real need to carry out a revolution in order to achieve many of the results you are looking to gain.
Following are a number of ideas that can be taken from the story above and that we believe can be implemented quickly regardless of which development methodology your team is currently using.
(1) Work in small/er chunks
Instead of working with a small number of very large requirements or tasks, break them down into smaller, more easily managed chunks that can be completed in shorter time intervals (days or weeks). This way you are making sure tasks don’t start taking up more resources than you originally allocated (because if your planning assumptions start slipping you will notice it within 2 weeks instead 2-3 months into the work) and most importantly, you will be able to deliver features faster to Testing and to Product Marketing and get feedback in time to make the necessary fixes and adjustments without affecting your release date.
(2) Increase the collaboration and communication between programmers and testers
If the idea is to get feedback about the features to the developers as quickly as possible then the best way to do so is to test sooner, many times, even in parallel to development.
You can achieve this in multiple ways, for example by inviting testers to run their test directly on the development environment as soon as parts of the features are ready (instead of waiting until everything is completed).
Another way is by having testers work with developers to plan and write their Unit and Integration tests in ways that will help them catch more bugs more quickly. And finally, how about we start teaching programmers how to run at least part of the manual and automatic tests written by the testers as part of their Sanity Sessions before committing their code? We see many teams where developers have their own Test Sets in PractiTest that they need to run before committing their code to the main branches.
(3) Have more automated tests and run them more often
This is one of the first principles applied by Agile teams but in fact, it is logical for every type of project. Make a commitment and a conscious investment in automation.
Start by instructing your developers to create Unit and Integration tests for each new feature or major bug fix.
You can also have your testing team create automatic tests to cover as much of your product as possible, and instruct your developers to code in ways that will make this functional automation simpler and more robust (for example, by using correct instrumentation of the GUI elements).
But creating your tests is not nearly enough. You need to have a framework that runs these tests as often as possible and provides immediate feedback to programmers whenever they’ve introduced a bug.
Today there are a number of very good Continuous Integration Frameworks (such as Jenkins, Bamboo or TeamCity), all of them can be integrated into PractiTest using our Robust API. Finally, you will also make sure your programmers comply with the golden of rule of “you broke it, you fix it. RIGHT AWAY!”
(4) Seek quick feedback and continuous improvement
The greatest enemy of improvement is human behavior: no one likes being criticized, and we mean that. No one!
That is why whenever we work on something, we don’t like showing it to others unless we feel it is complete and our audience will be able to understand “exactly” what we did.
But as you may already understand, this is counter-productive in programming because if we wait too much to get feedback then we won’t be able to implement any changes without missing our delivery targets.
So what can you do?
Basically, overcome the trauma of being criticized by making it a policy to have everyone present their progress to the rest of the team and product marketing – as they are working.
Work on creating a culture where people know how to give and receive feedback. You can achieve this by making sure feedback is always directed to the work and not to the person, and also by having people give feedback on both the good and bad things in the product (and not only focus on stuff that needs to be fixed).
It may not be easy at first, but it will be easier with time and the value gained by this is simply incredible.
(5) Embrace change and work accordingly
This may be the cornerstone of Agile – the realization that regardless of how hard you work on planning your project and how good you are at it, in the end, stuff will change and you will need to adjust your plans.
But, slogans aside, how do you embrace change?
First of all plan less, not less deep but yes, less for the long-term since you cannot foresee exactly what your reality will be a few months down the line.
Seek feedback sooner rather than later, make sure that if you do need to change features and plans, you know this 2 to 4 weeks into the project and not 6 to 9 months into it.
Plan for change and make sure your team is aware that change will indeed come and it will be accepted; this makes it easier for them when they are faced with that reality and need to cope with it.
Making small changes should be part of your work culture.
One of the best principles you can adopt from Agile is the understanding that just as the product and the requirements are constantly changing, so should your work processes be dynamic and adaptive.
Be open to asking questions about whether you are working in the best and most effective way or if you can make small (or large) improvements to the process?
Be open to feedback, seek it and even reward the people who give it. Once you are able to introduce the acceptance of feedback into your company culture, you will see how things really start improving, almost on their own.
Yesterday night we released a new version of PractiTest. This update comes with a number of features and improvements.
- Improved filters. New GUI that makes it easier to manage your filters, as well as the ability to see the filter criteria for the whole filter hierarchy. In addition to this, the filter pane now loads a lot faster than before.
- Enhanced attachments. Graphical attachments now have a thumbnail that allows you to preview the image before opening it.
- Additional functionality to issue integrations. Displaying bug IDs in reports.
- And many other enhancements and features.
As always, we want to hear more from you about the stuff you’d like to see if include or improve in PractiTest. Feel free to contact us via our support team.
See you all soon in another PractiTest update!
Yesterday (Oct 22nd) about 5:45 PM GMT (10:45 AM PDT) our web hosting provider Amazon (AWS) started experiencing performance and connection issues.
These issues caused a large number of Internet service companies, including PractiTest, to become unavailable.
We were able to regain temporary access to our servers between 11:30 PM GMT and 12:15 AM GMT, but then the system came down once again.
After evaluating all our options we decided that the best way to solve this issue would be to bring up our latest backup of the system and restore it to a completely new server farm in a different Amazon hosting zone.
We performed this operation and we were able to bring full access to all our servers and services at Oct 23, 8:45 AM GMT (1:45 AM PDT).
Still, the last full backup that was available to perform this operation was from yesterday at 12:00 noon GMT. This means that all information entered between 12:00 noon GMT and 6:45 GMT as well as what was entered for the 45 minutes the servers were up later in the day was not restored.
As a serious web service provider we understand that access to project data is your highest priority and our top-most responsibility.
We are still working to try to bring back the information that we were not able to restore, and we will work with the accounts affected to make it available to them as soon as possible in a separate server.
In parallel we are working on understanding what measures we can implement to lower the risk of issues like this happening once again in the future.
We apologize for any troubles this issue may have caused and will be happy to answer any questions you may have.
* More on this Amazon AWS outage:
We are pretty excited about the announcement released a couple of days ago around the successful collaboration between SAS, Redhat and PractiTest, as you can read from the official press release.
The announcement comes to communicate the vast success SAS has been having managing the testing and Quality Assurance aspects of their deployment projects in the UK.
As was described by James Ochiai-Brown, SAS Senior Solution Architect: “PractiTest gives us the ability to manage our testing in a structured way, and more importantly, demonstrate to our clients the quality assurance that they demand…”
This PR also comes to emphasize the value gained by the relationship between PractiTest and Redhat, as part of the Redhat Innovate program, to which PractiTest was accepted late last year.
If you have questions about any part of this Press Release feel free to contact us.
Last night we released the latest PractiTest update that included a number of features aimed at improving the reporting and Testing Intelligence capabilities of the system
- Dashboard graphs and tables in reports. This was a request that came from a number of users who wanted to add graphical elements to their reports. The feature allows users to add any graph (pie-chart, bar-chart, or progress graph) or any distribution table from the dashboard to any report in PractiTest.
- Select what parts to include in your Detailed reports. Another field request that asked to control the sections included as part of your detailed reports. Starting today you can select whether to show (or not) sections such as comments, history, etc as part of your reports.
- Control the colors of your dashboard graphs. A simple yet powerful feature that let’s you choose what colors to display for each category in your graphs.
- Choose where to display graphs’ legends. An additional field request to define where to place the legend describing the graphs. You can now choose if you want to display this legend inside the graph, at the bottom of the graph, or not to display the legend at all.
- Graph entity preview. This one is the team’s favorite 🙂 – a simple preview of the dashboard items within the settings, to show you how the graph will look based on the definitions you just set or modified.
Clearly we are interested in getting your feedback on these or any other features of the system. Send us your requests to our user forum, and your comments to our support (support-at-practitest-dot-com).
See you all soon with another PractiTest update!
* Also for this upgrade there was no downtime.
We all see it happening and a lot of us are part of it – the distributed testing (and development) phenomenon – a project tested by engineers in different locations either locally – working from home, or the office, on different shifts and in different departments, or internationally – anywhere in the world, and in a range of different time zones.
QA managers and testers know what a coordination and management nightmare distributed testing scenarios can be. If everyone isn’t on the same page, not only do testing teams miss deadlines but they don’t catch and properly follow up on all issues and bugs, and this leads to… well, we all have a story or two of where this leads.
Although distributed testing has been around for years, there are teams out there that still use Excel to manage their testing procedures. Now, don’t get us wrong. We think Excel is great. We use it too, to keep track of our departments’ budgets, for some of our scheduling and to import/export testing-related files. These days, Excel can even be accessed via the Web and mobile and it does enable a degree of collaboration. But, for managing testing, the most efficient – and dare we say, smartest – method is to use a dedicated testing solution, created by testers for testers and the way they need to work.
As lots of you already know, PractiTest is a great testing solution. It allows managers to manage and gain control of their processes in the way that makes sense for the particular project, taking into account the departments, assignments, and people involved. There are so many features that make it a thorough and dependable testing management solution but here we’ll mention just a few – those more relevant for distributed testing.
- PractiTest facilitates the communication that is crucial to successful distributed testing – by keeping everyone up to date with tasks, issues, bugs, statuses, etc. and making the work routine clear to all. And, because it’s cloud-based, no matter where in the world testers are doing their job, the system is fast and responsive.
- QA managers simply set up and organize test runs, assigning them to testers – wherever they may be. Each step performed reports independent results including actual outcomes of the test, so the status of who’s working on what, and where it stands is clear to all.
- Issue workflow is managed in a single system including work on bugs, enhancement requests and other tasks. For example, managers can define the workflow for bugs, specifying which groups may perform the different transitions between them so that rejecting issues can be limited to team leaders, or permiting only testers to transition a bug from Fixed to Closed, etc.
- Duplicate bugs are prevented from being submitted – a potential scenario when many testers are not necessarily in direct contact. The system scans the database for similar descriptions to the bug currently being entered into the system.
- Managers can set up email notifications for alerts on work on issues of particular importance.
- And more…
We encourage you to find out more about PractiTest so that you too can make distributed testing manageable and successful.
As you may have noticed, earlier today we modified our Website.
Basically we wanted our users and potential customers to understand why our Intelligent testing platform improves the QA planning, design and execution processes; ensuring product status transparency and reducing time to market uncertainty.
As part this update we also introduced our new logo, that includes a drawing of our mascot, the testing fox.
Why did we add a fox to our logo?
For many of us (testers) this is a trivial question, but still to make sure we don’t leave any doubts out there, the answer lies in the similarities between the “personal characteristics” of a fox and those of a good tester.
Think about a fox for a second, how he behaves in nature and what traits help him survive and even exceed in his surroundings.
You can say that in order to survive in the wild a fox he needs to be:
And the list goes on and on…
Now let’s look at the Tester in his natural habitat:
SMART – OK, who’d ever say that his job allows even “dumb” people to succeed… But in the case of testing we know that due to the level of complexity required of us, as well as the multitasking and context-switching that define our day-to-day tasks testers need to be smart enough to quickly grasp the challenges ahead of them and successfully approach them in the most intelligent way – without wasting time over-analyzing the situation.
CRAFTY-ness in testers refers to the way we are required to make use of the tools we have at hand, and at times even to come up with new tools to complete our jobs.
CREATIVE-ness allows us to look at an issue and come up with interesting and new approaches to understand and solve them. Sometimes it is how to test a component, other times it can be how to find the complete scenario of a difficult bug, regardless of how you see it, a tester needs to be able to find the solutions by reframing or zooming out from their tasks.
SNEAKY – as the saying goes, it takes a thief to catch a thief! And so, a tester needs to have a sense of sneakiness when he sets out to hunt for bugs. One of the tips I give beginning testers is to go and check the bug database for defects that were detected and fixed in past versions. Understanding the way bugs sneak into the system is always a good way of catching new bugs that used “old ways” to sneak in.
ADAPTABILITY is also something that allows a good tester to juggle between the testing tasks, bug verification tasks, “trouble-shooting with support” tasks, feedback to developer tasks, and all the other tasks that fill out our daily task list.
Finally INGENUITY or cleverness is what allows us to keep coming up with answers and different approaches to the challenges faced everyday.
So, why did we choose a fox? Because a tester needs to be like the fox that works in small groups and even though he’s not the strongest, or the fastest in the forest, he is still able to catch his prey successfully and elegantly.
“We were looking for a solution to organize our testing process and keep control of our quality. PractiTest supplied what we needed, with its organized and structured test case management solution.”
Gilad Breslawer, QA Team Leader, Plimus
“PractiTest enables us to organize our tests and report bugs into one database, in a unified and pre-defined mode, providing us with much-needed order and enabling us to streamline our testing process.
As a service provider working in complete transparency with our customers, we found the PractiTest dashboard and reporting mechanism a superior tool for providing our customers with a clear and precise view of development status. In this way PractiTest helps us reach our goal of maximal customer satisfaction.”
Hila Vax, QA Team leader, Symcotech