While testing a software application, no matter how thorough you are, there is always a possibility that some bugs manage to hide from you to pop up only later[ unfortunately after the certification ]. These bugs may be just typos in the GUI text, badly broken flow which you never thought of or even a missing/incomplete functionality from the requirement doc. Sure you did all the sophisticated planning and rigorous testing to find these bugs early, question is….Did you also include all the stake holders in the testing? What are collaborative strategies you adopted to nip these bugs in the bud and stopping it from popping out with confetti in the release party.
Different functions (ex: business team) of the project team looks at the product in quite different angle and perspective than the development or QA does. Idea is to bring all the players into the game…i.e not only use all the brains you(QA) have, but all that you can borrow….
Apart from being more vigilant & doing accurately-precise testing which you always do.. you can be more creative in getting the testing help from the resources outside your own QA team….i.e other stake holders in the project like business owners, Business analysts, Technical/project/product management, developers and in some cases internal partners/users. I always believe in the theory that “More users find more bugs” because “Many Eyes are Better than One Pair”. It does not really make a difference for the product quality whether QA finds the bugs or some one else did… as a QA lead you still win because it was Test strategy and the process which kept the product-under-test peeled & exposed to many others so all the issues were taken care before counting down for the launch.
You can involve other stake holders with the product-under-test in different ways at different stages of the product development life cycle. Here are some examples….
- Developers: Developers are our close cousins and our technical partners, so feel free to place an increased portion of the testing in the hands of the developers , always remember to start early in the project, device all possible test scenarios, put them in a decently presentable document as one-line Test scenarios so it’s easy to grasp. Forecast your test scenarios to developers before or while they are coding. I am sure they love to address them all to make sure that software is built to weather your tests.
- Internal partners/users: Now that you have the build shielded to counter the your test scenarios…you have less bugs in the build and you spend less time opening and resolving bugs..Once you have a decent build which passes most of your test scenarios..Open your application or interfaces to your internal partners or users to get the quick feedback on the product under test.
- Tech/Project/product Managers:Send out an e-mail to Technical managers, Project/product managers with the entry point(URL or some other means to get to the product) to your application with some test data for different test scenarios. Being stake holders, I am pretty sure they love to use their experience and add value by providing feedback and tips or asking some great questions which may help tune your test strategy and testing. They may be busy….. leaders loves quality…they always have time for quality.
- Business: And finally the business owners..They are the only people who knows precisely what the business is, and how it operates.They are the most qualified people to check a system to see if it will deliver any benefit to the business or organization. Come out with best UAT plan and test cases to involve them in the testing with well prepared test data. UAT helps to try the system in the context of the business environment it will operate in and business owners will be able add lot of value by providing the feedback. Also they are the only people who can see if there are reputation or legal risks in the product implementation which we as a QA may not be able to see.
I am sure non-qa teams are busy to get involved in product testing, you must free them up to conduct proper tests on a new system. Because in any product, quality is everybody’s business and desire…Every functions of the project team has quite a players.. getting them to play as a team to deliver the great quality-product is the key..Idea is to make sure that the product meets the business expectation, not only the specifications. Even if your approach to get them involved is unscientific or informal, don’t be shy in asking for help, bump up your game and quality by involving and including others in your testing efforts…. and….. be open to feedback and opinion from others which may differ from that of yours….
