I am Hussain and have testing for around 8 years. I have a question rather needs help to check whether I am in the right direction.
I have recently joined an IT firm in which they want me to implement the QA process. Let me explain a bit about how the projects are going and what the system is so that you could have a better understanding.
It is an IT firm working on a project for the last 3 years. (They do have other teams and projects but i am referring to the one i am working on). It includes testing of almost every type like functional, regression, UI etc. They are working on Agile. Sprints are of 2 weeks. and following the Scrum. Using the TFS to report bugs / writing user stories and confluence for other stuff.
My findings to implement process in such environment are:
1- Test case writing. Developing a regression test case suite. integrating those test cases with the user story / bug. Also will keep in mind that there will be some user stories / bugs whose test cases will be written once.
2- Starting to write single page sprint plan before every sprint. This way we shall be able to see how we are going to test and what will be included or not.
3- Writing test report. Which will include the results/ test cases / user storues / bugs we worked on and what could be included and what not depeneding on the hurdles we might face.
Am i going in the right direction? Is there any other process you would like me to include? Please feel free to guide me or if there is any other information you need from me. I would be gladly provide.
If you are an Agile company the testing process does not have to strict and overly documented, but it is better if it exists and that everyone is aware of it and agrees to work according to its guidelines. I have written test strategy docs that nobody really cared about and lengthy detailed test planes which people just skim trough. Eventually I just ended up using “symbolic” test plans in TestRail, very minimalist kind of a sprint based test plan with user stories and tests sets for them.
One of the most important things about implementing a process is to make sure that you have enough time to do proper testing, to test as early as possible - instead of waiting for the code to be deployed to a test environment maybe ask the developers to give you a local setup, you could test in parallel with development by just pulling the latest changes from source control. This way testing will give very quick feedback meaning that the return of the investment will be high. Of course you will need to verify the developed features once they get deployed (usually after a Sprint demo) but by that time you should have enough time to automate the tests, if it’s viable or just do a quick smoke as you already thoroughly tested the features - just to eliminate the environment specific issues.
I’ve been testing in this manner for the past few months and I can tell you that defects get resolved a whole lot sooner if they are caught very early - and it’s a whole lot cheaper to fix them as well.
Thanks for your quick response. As far as Testrail is concerned I had that in my mind and i have seen my companies using it but as you know it is free to some extent and if you want to use it professinally you have to pay for this
My company had two arguments when i suggested testrail to them:
1- We already have two tools, TFS and Confluence… why to add third one.
2- It includes cost for which we are not yet ready but we can look into it in future (But when nobody knows.)
Regarding testing time yes I shall keep that in mind that there should not be that much documentation added that would result in less time for testing
Early testing suggestion is super awesone. I shall surely make it work in coming days.
I just used Testrail as an example, since that’s what I’m using at the moment. But any test management tool should have a test plan functionality that is pretty similar so you can organize and group your tests.
I think you should ask your team members of the project this question. If you want to create a self organizing team the input has to come from them. Maybe they will suggest something that they heard of.
Also make sure that your devs review your testcases. They might come up with something they thought of during programming the project.
I agree with @mirza, don’t waist time on paper work no one is interested in. We work with JIRA and Confluence where a lot of the documentation just writes itself by including bug lists automatically and live.
Additionally I would suggest trying to add testers into the workflow as early as possible by attending 3 Amigo meetings. If you don’t do them already I highly recommend them. It fits with the idea of “larvae hunting” where you try to find issues like misunderstandings before any wrong code was ever written.
Test review are great. I have seen many different ways to do them. There are peer reviews within the test team. Or a second opinion from Dev or OPS. Some teams have a review by Product, a kind of customer acceptance in the sprint. Demos are also great for feedback on your approach even if they are a bit late in the process in case something wasn’t done well.
Adding to the very useful ideas and recommendations of the previous contributors.
I’d like to encourage you and reach out to the other teams (or their test members) and check how their processes are.
Yes, you are just in one team. And yes, you want to focus on their processes. But it won’t hurt, to explore what other teams within the company are doing. To get some impulses and ideas and learn from each other.
And another point, I’d like to mention. Ask your team and maybe some management representative what level and detail of reporting, documentation they’d like to see. Maybe they are ok with meta-level information if you do spend more time with actual testing.
Thanks everyone for your valuable input. I would surely involve my team into meetings. Thats a great suggestion as well. Approaching other teams for information is also good to follow plan.
As far as management is concerned I had approached them already to get the idea of what type of implementation they want or what exactly is thier requirement. But both of my seniors told me that its entirely upto you to implement the process but we need something in place.
After having discussion with you guys it has now cleared to me that in agile its less documentation and more practically done testing. I shall not go further with the documentation as this will only put more burden on the team and we might miss important testing parts.
