- This topic has 9 replies, 10 voices, and was last updated 7 years, 3 months ago by
.
-
Posts
-
Some software is more testable than others. Some organizations build more testable software, and create conditions that facilitate better testing. Instead of merely waiting downstream for whatever your organiztion floats down to you, what specific things can you do early in the developent or maintenance cycle to help you do a better job of testing? Perfect Software
Plenty of things:
1) Listen
2) Test what ever artifacts that are being worked on (documents, mocks, strategies, list of concurrent projects)
3) Wonder and consider whyWell, I never ever wait downstream so I wouldn’t do that.
What I do is sit with the developers, see what they are up to and just help with stubs and mocks, automation framework, read design documents, write logic to be tested and so on.
There is tons to do before I actually get some working software to test on.Interesting question – though I suspect that reflecting on this question will lead you to a few other questions as well. The test department at the company I work for was initially required (for the first 15 years or so!) to simply provide a “final stamp of approval” – so their activities often resulted in discovery of defects close to delivery deadlines and consequently much frustration from management when deadlines whizzed by. Over the past 5 years that I’ve been here, I can see that the attitude has started to shift towards testing earlier in the life-cycle but the predominant view has still been that it is simply testing of the product that is being shifted to the left.
The mindset shift that needs to take place (and I think the point of your question) is that the test team could play a much more holistic role in the upfront work done to plan the delivery and to execute before actual system/acceptance testing is required. While I agree with @kasper on the activities he’s listed, I still believe these are slightly more reactive activities and testers can do so much more.
So, for me, this means that testers should be part of the project kickoff meeting and should review the project charter (if you start off on the back foot or not being involved in the project, you can bet that you’ll always be on the periphery). Test effort is consuming more and more time as a percentage of total project costs so this isn’t an unfair request. If you know what the project is meant to deliver and you’ve contributed to the overall mission of the project, it makes sense that you’d be more likely to delivery according to expectations. If your project captures requirements (certainly hope that they do!), then testers should be reviewing those requirements for completeness and testability. There is no point in capturing a requirement if you cannot validate its fulfillment.
Testers should also understand the end-to-end architecture of the solution and should be actively involved in the design and testing of test environments that may be required to test the final solution. I work for a satellite broadcaster so many of our changes cannot be tested on the live infrastructure prior to deployment. Instead, we need to build appropriate test infrastructure (which developers also use) to test our solution prior to deployment. Of course, you also need to test the infrastructure prior to using it for the actual testing. A good portfolio of test equipment and harnesses is vital to successful test execution.
On a recent project, I also found that working with the customer (if that’s possible in your case) to define and flesh out the acceptance criteria in as much detail as possible is also a really good way to buy time upfront. Having a customer understand exactly what will be delivered and how you plan to test it will likely cut out much debate and unhappiness later in the project.
Sounds like you’re looking for arguments to do agile!
Apart from building a test environment, testers can already create tests. If you use Behavior Driven Development in an agile environment, testers are very much involved in the full software development process.
Testers can create tests in the style ‘Given – When – Then’. This way the functionality is clearly described in a human readable way. You can discuss this with the business department to make sure that this is the intended behavior. This all can happen before the software has been written!
You can already run the test in an automated regression set. For sure the test will fail, but this guarantees that your test is fine. (‘Test your test’.)As soon as the software developers complete parts of the software, these parts will show up green in the test results, meaning that part is finished indeed. (Check!) Slowly more and more will turn green. This way you have a perfect overview of how far the developers are and you can estimate when all might be finished.
Additional advantage: In case a new checkin of code breaks existing code (regression), it will show up immediately. The surprise is no longer at the end of your project. Software developers can fix the problem immediately, before the problem gets covered by a lot of new code. Fixing immediately is the cheapest way to go.Early involvement can but does not necessarily produce higher quality at lower cost. Beware the Testability Trap! https://testhuddle.com/unconventional-wisdom-v3-testability-trap/
Robin F. Goldsmith, JD advises and trains business and systems professional on risk-based Proactive Software Quality Ass
One that I’ve found helpful no matter the environment is to ask those awkward questions. It’s how I taught my current workplace that they need to have the tester involved from the start – while they were working in a waterfall environment, I often wouldn’t know about the changes until the code was ready for test, and the questions I’d ask kept pointing to holes in the requirements (to be fair, I’m the first test specialist the organization has hired, so they had no real idea what to do with a tester until they got me!)
Now that we’ve moved to a more agile way of doing things, I’m not finding as many missed requirements, and I’m involved from the beginning. I’m often giving suggestions about ways to do things from a user perspective as well as pointing out connections the developers may not notice – testers tend to be more likely to have a broad overview of the system than developers, where developers are more likely to have deep knowledge of some areas.
Sounds like a very typical question yet interesting. One thing could be done early in the development cycle to improve testing is that testers should be involved in the every meeting that happens with developers. That said, testers should have complete knowledge and purpose of the product that about to develop by developers. Testers might need to start testing each every code from the word go. Testers might need to be gathered every week or as frequent as possible to review their effort and drawback. It helps to identify right tester, right tool for the task and improve testing.
You can review your documentations (acceptance criteria), stay with developers and start testing from the first lines of code, gather as much you can informations about the scope of the software (ask why? ).
- You must be logged in to reply to this topic.