Development organizations are often attracted to agile development practices with the promise of increased test automation to help their teams deliver higher quality faster. It’s not just any tests though: We look to automate the kinds of tests that provide rapid feedback to tell us if we have built the product right. But which tests do we automate, and when?
For PMs working in IT application development projects, which resource is the most important (other than people, of course)? For many it is a Technical Quality Assurance model that supports highly repeatable test cycles.
You think you have a handle on how to deliver your projects. Then a mandate comes down that your development team is “going agile”. This is an understandably scary proposition for some people. Here we look at general patterns, models, values and practices that lead to success when thoughtfully practiced by motivated individuals.
Using continuous testing, one can immediately detect problems in code — before it’s too late and problems spread. Using a clever combination of tests, tools, and techniques you can tell right away when there’s a problem and it’s easiest to fix. The author uses a case study to illustrate the benefits of continuous integration (CI) and how it leads to better quality control (QC) and quality assurance (QA).
Question: I’m so confused. I was a Quality Tester at my last job, but here the employees seem to use the titles Quality Assurance, Quality Control and Testing interchangeably. I started out in a more traditional organization, but now I’m a tried and true agile believer. Since I have no job description, what are my responsibilities?
The three concepts are often used interchangeably. Ask what it means in your new organization and accept that as your role in your workplace reality despite the real definition.
Find the specific meanings for each term from a university professor in the town where you work. Use that information to correct the organization so that they use proper terminology.
Once you learn your job description from Human Resources, create a new title for yourself so that others can understand what you do. Perhaps Defect Engineer would be apt.
Since agile teams work without formal processes or documentation, there is no need to answer to a particular title. Everyone on the team is merely a team member.
Question: Amazingly, my team and I have come up with the idea for a very clever, innovative product and have secured time with the board to present it for potential production by our employer. We would get a cut of the profits. What do I need to consider in order to present the most professional case for getting this produced?
Why take a percentage of the profits when you could have it all? Find an entrepreneur to back you, quit and make a fortune.
Check with other organizations with similar production facilities to see what costs will be and where it is best to buy raw materials; then you have a realistic selling price to present.
Use social media to begin to build demand for this item. If you can show the board a high number of Twitter, Facebook and YouTube hits, they will be convinced to support you.
Think beyond the product itself to other considerations from the corporation’s point of view. Bring in information on more than your design, and show you would be valuable business partners.
For an agile project to progress smoothly, the backlog must be groomed and ready for each sprint. That work must be included in your project plan. This article gives you five points to consider when planning that work.
Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. How can we act more productively?
Have you realized that your organization is not putting enough attention on requirements? Wondering what types of tools are out there and how much they cost? Do you even need a tool? And if so, what kind?
The waterfall methodology for projects is aptly named, because it is equally painful to try to go back to prior phases of a project once the effort has advanced to the next phase. This article will outline two reasons to avoid waterfall, and three ways to approach software projects that are more useful.
If Kanban works well on specific software projects, can it be scaled to facilitate Lean throughout an organization? Here we look at how Kanban can be thought of as a general purpose change management approach for your organization.
This procedure describes the process of testing software code or products by the test team. It documents the procedure for the entire testing cycle: generating test plans, scheduling tests, conducting tests and reporting test results. This procedure applies to new development, as well as major and minor releases, including customized solutions delivered to customers.
Do you know how to thoroughly and efficiently test the software product you have so painstakingly built? Don't risk delivering a faulty software product due to insufficient or unfocused testing. Use this list to check whether you are testing smart--or just testing!
Defining and measuring software quality attributes is critical to the success of any distributed application, and performance is no exception. Distributed applications must demonstrate performance in order to assure immediacy. Use this project plan to stay on top of your Performance Testing.
Selecting the right testing tool means you must look at a myriad of factors and how well each candidate tool meets your application's testing requirements. This form will help you evaluate the candidates and select the best testing tool for your app.
Governance happens in projects all the time, and a well thought-out governance process can be a powerful project tool. In this article, we will examine why governance is necessary, where governance is most effective and how we as project and program managers can use governance to powerful effect.
"Nothing travels faster than the speed of light with the possible exception of bad news, which follows its own laws."