How to improve agile environments as test lead?

Question

I'm a test lead in a company and have only a handful of people in the testing team.

We are working on multiple projects simultaneously. Our company is following an Agile methodology. In some time, when we start 1st QA cycle of the projects than getting many miscellaneous issues which should be done in unit testing. So, our 2nd QA cycle also over into the fetching unit testing point.

I had already shared covered unit testing test cases and scenarios of the basic CRUD operations to the developer team but they are not performing it.

I had also discussed the same situations with PM & PL, but no result is coming. In the end, We aren't able to test the depth of the project and have to face all bad feedbacks from the management side. Can anyone help me to get out of the situation?

Answer 1

I would suggest reading the Crispin/Gregory books: Agile Testing/More AGile Testing. A team that has moved to Agile, needs to get out of the thinking of QA/Testing as a separate silo that tests N + 1 sprints after dev is done. Instead, find ways to include them into the teams, embed and let them add questions. Allow your testers and devs to sit and pair for a couple of hours of day, asking questions about what they would test, what they might build, will do a heck of a lot more good in the long run.

Second, you need to start thinking about Continuous Delivery. Maybe not all the way to Production, if you are not there yet, but being able to quickly checkout, build, spin up environments, deploy, and then test subsets of the source code, goes a long way in speeding up testing and delivery. (Btw, you may want to talk about how much time you are spending on automated testing between devs and testers, to help add some checks around this process.) You would be surprised how many of the build issues testers run into are caused because the package/build/deploy process is carried out irregularly, meaning that not only are fixes being waited on to test, but that when they are, you have a long lead time from inception to deployment. Even if the team goes to work on those bugs, the schema in their mind for the work that it was supposed to due may not be there, which means more time to deliver.

Now, on the unit testing side. I suggest you get a chair/book/video and teach your testers to write some of those unit tests. (make them really good at it, make your own build lines if you have to, to get it done.) Then when they you start reporting bugs FASTER than the dev team can deploy to you, they will ask why, and you can say, oh, because we decided the best thing we could do for code quality, was write our own unit tests, and we caught it right away. Eventually the bells will goo off, and the developers will realize they need to be doing some level of unit testing. Results matter.

Answer 2

Switching to Agile is not just about the process, but also about engineering practices. Agile engineering practices are described nicely on the technical excellence pages of LeSS, which include a lot of testing practices.

Organizational Agility is constrained by Technical Agility

From what I read in your question is that your teams have not yet understood the importance of these practices when building adaptable software in small iterations. QA-cycles sound like Agile anti-patterns. Quality is a whole-team approach and part of each smaller feature, not an after-thought.

As a Test Lead I would try to build a community of quality, suggest by Alan Page in his Adventures in Modern Testing talk. This community should try to infect everyone with the test virus.

Some things that helped our teams:

• Clean Code (Robbert Martins great work: https://cleancoders.com/)
• TDD Coding Dojo's (Emile Bach: https://leanpub.com/codingdojohandbook)
• Training in Exploratory Testing for all team members (Developers, Testers, Product people)
• Buy some Agile books: https://agiletester.ca/
• Sparring about http://moderntesting.org

Answer 3

Cycle system in Waterfall model,

1. You will get the build in Testing phase of SDLC. QA team performs testing as per requirement document and raise the defects (call this cycle 1).

2. Development team resolve the reported issues and assign back to QA team, and QA team verifies (Regression testing plus closes the existing reported tickets (we call cycle 2)).

3. And still there are some issues then same repetitive steps

So in this process, There is very tight schedule for each phase and every allocated Team has to complete their task within decided timeline. So sometime developer do not have enough time to test in detail or sometime QA missed something and the final conclusion is, as you have mentioned in your question.

QA process in Agile,

I'm assuming that you are using Agile methodology and everyone is pretty aware of Agile Scrum process in your organization, If not then please ask the top management to conduct some agile scrum session. To make the personnel/team aware.I'm sharing my personal experience where i felt it was smooth process. It might helpful.

1. All the project requirement (new feature, reported issue, enhancement, change) divided into task and keeps them backlog

2. There is sprint planning where the agile team(Dev+QA) decide to pick priority task and move them in sprint backlog.

3. There is product environment system (QA, Staging, production), and deployment take place on each environment only if it tested on earlier one and has green signal.

4. Once developer done with the allocated task, after initial testing (unit or smoke), he/she deployed the code on QA server(server depends as per organization choice) and assign that ticket to QA team member

5. Ticket has to be tested by allocated QA and make it pass for next server deployment if everything is fine else allocate back to developer along with found issues related the that ticket functionality.

6. After staging deployment the same ticket needs to be tested and same moved as passed for next server. Then sanity test after production deployment.

So in this process all the issues get filtered step by step. Your team could deliver the quality product with time efficiency.

You can refer below key point:

• Allocate your QA resources in development team. Lets say there are 3 project and you have 3 resources. then individually allocate each member with team

• Keep track of whats going on in each project. you can get the status in daily stand up meeting.

• Before production deployment, do sanity test of each ticket by your self which passed by your team member, so you could point out if anything missed by them.

Answer 4

If possible you can follow below steps:

1. You can make a practice to not accept a build for Testing until and unless it is having basic stability.

2. Do not "actually start" your QA cycle even if it is considered as started by other people.

3. I believe you must be sending cycle status mail on regular basis to all the stakeholders of the project and even if it's not the case you can highlight this issue by sending a special mail to all the stakeholders.(You can use some other communication medium as well but make sure it's in written mode).

4. And be sure to not sound rude but it should be in polite yet strong manner.