25

Get the whole team to work on the problem. Given the arrangement you've discussed clearly the team needs to look at options to resolve this. The problem itself seems fairly endemic in all of the organizations I have worked with. It seems inevitable given the setup unless proactive steps are taken to address it. A frequent issue is that there is no 'one ...


18

A good starting point is to define what quality means in your context. And then find out ways how to measure it. It seems you want to measure something without saying what that something is. Having said that, we can hardly tell you that here, but perhaps we can give you some starting points that you might use in discussions with your teams and other people ...


7

Great Communication Brings Great Results Being last in line, QAs keep facing this repetitively. QA should proactively communicate delays and respective risks to stakeholders. I’ve never seen any agile project where every sprint came in on time. Start with finding the reason what is causing the delay. There can be multiple reasons for the delay: Estimates ...


6

For me it is about measurable faster delivery of valuable features, while reducing downtime of functionality. I think good products and teams go faster and faster overtime. This might be different than most people have experienced, typically software projects go slower and slower overtime. Which I would say is due to "bad quality" in Functional, ...


5

There are a few different ways to approach this problem. From a Scrum perspective, your Development Team does not have sub-teams. You may have specialists, such as people who specialize in testing, but the whole team should be involved. Rather than putting the QA specialists in a position where they must test everything at the end of the Sprint, the whole ...


5

In the spirit of working in a multi-disciplinary team, I think developers should participate in the QA process if there's a backlog of work, (or even if there isn't). I think it's bad practise for the development and QA teams not to be closely integrated - As far as possible, they should be the same team, and that makes it easier for developers to switch ...


5

We have an issue Issue for who? Sprints are a completely artificial unit of time usually set up by managers who do not do your work anyway. If you're breaking this artificial deadline but the clients and customers are happy with the product, perhaps it's time to change the way you as a team work. One problem with the way you seem to work now is that the ...


4

This is an example of building a software system for the marketplace. In this case, you have many customers or users, each of which has its expectations for the system. However, someone must have identified that there is a need for the product in the marketplace. If someone did not justify the possible need or desire for the product, how did anyone fund the ...


4

Not Actually Agile As is common, people have taken a waterfall process and slapped an Agile label on it while being un-agile. The classical Agile model doesn't have a separate QA team at all. There is a single, small team, who report to a product owner. The product owner is responsible for acceptance, and the developers are responsible for pre-deployment ...


4

Tell your devs and management that a Backlog Item isn't "done" until it is tested. So PBI don't get "done" at the end of the sprint, they remain unfinished because the team "forgot" to schedule the necessary QA. The whole Scrum team should have a Definition of Done and QA belongs into it. If you can handle irony or sarcasm, ask ...


3

Agile is known everywhere. Most folks know the terms and activities. That is your main challenge. What you see is not agile. but it is likely that the people involved are not ignorant about agile and terms used. More learning is required by you. a starting point for testers finding themselves in a new company and wanting to do Agile, but still not knowing ...


3

These are the metrics our company uses in priority order: Number of support cases per number of active users Number of errors generated and logged by our application This covers a number of underlying aspects of software development: How user friendly is the product? If it's not then you get more support requests and or less users. The more errors logged, ...


2

Detailed post-mortems With a clear objective of answering one question What should we have tested that would have helped us avoid this situation in the first place. The unstated side-effect will be for folks to ask "what (test wise) should we do going forward in our work to avoid repeating this?". However you don't need to tell engineers that ...


1

Well you'd likely start by addressing the Manifesto, and trying to get the company behind some of these principles. And the values: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan (valuing left over right, but ...


1

Like some other poster said: work together as a team. To make this possible ensure you speak the same language. We have adopted BDD in our team and it's made our product owner, developers and testers speak the same language and it's made it far easier. It also means us testers can start writing test scenarios at the start of the sprint! (even if there is no ...


1

The QA can push back by not accepting „new work“ in the sprint, which effectively means the testing task will be delivered in the next sprint increment. This push-back either leads to more testing and less stress, or it forces the developers to integrate the testing planning better into the development process. This is a result of a development Organisation ...


1

My idea is preety simple. Prepare regression automation suite and setup in CI & CD pipeline and add this as a post build action. So for the new deployment it will run can help to do the regression and sanity of the application. Your focus during the Sprint should be starting automation of repeatative tasks and push this in CI CD pipeline daily. If ...


1

My experience, and I heard the same from a couple of colleagues that manage companies in the test automation domain, is that the best approach is to start small and "look under the street-lamp". The logic behind it is that there is simply too much to learn and try in order to achieve good test automation (or checking, whatever) and while you are doing that ...


1

Well, if you just want an entrance to test automation (and keeping in mind what @JoaoFarias said about the difference between testing and checking) the best way to show 'something' to your superiors would be to automate some key test cases you already have. A typical example is automating the login page. There are multiple tools available: Selenium is ...


Only top voted, non community-wiki answers of a minimum length are eligible