Here are some interview questions that can be useful when hiring a software tester:

1. Can you describe your experience with software testing? What types of testing have you performed (functional, regression, performance, etc.), and what tools have you used?

2. Can you describe your experience with test automation? What tools and frameworks have you used, and what types of tests have you automated?

3. Can you walk me through your testing process? How do you plan tests, write test cases, and execute tests? How do you track and report on defects?

4. Can you give an example of a time when you found a critical defect in a software application? How did you discover the defect, and how did you work with the development team to resolve it?

5. How do you stay up-to-date with the latest trends and best practices in software testing? What resources do you use to stay informed?

6. Can you describe your experience with exploratory testing? How do you approach exploratory testing, and what techniques do you use?

7. How do you prioritize testing activities? What factors do you consider when deciding which tests to perform and in what order?

8. Can you give an example of a time when you had to work under tight deadlines? How did you manage your time and prioritize your testing activities to ensure that the software met its quality goals?

9. Can you describe your experience with performance testing? What tools and frameworks have you used to measure software performance, and what metrics do you track?

10. How do you work with other team members, such as developers and product managers, to ensure that software meets the requirements and quality goals? What strategies do you use to communicate and collaborate effectively?

These interview questions can help you assess a candidate's experience, skills, and approach to software testing, as well as their ability to work effectively with other team members and adapt to different situations. You can also ask follow-up questions to get more detail and context around a candidate's responses.

The software development life-cycle (SDLC) is the process of planning, designing, building, testing, and deploying software. There are various models for the SDLC, each with their own advantages and disadvantages. Here are some of the most common models:

1. Waterfall model: The waterfall model is a linear, sequential approach to software development, where each stage is completed before the next one begins. The stages include requirements gathering, design, implementation, testing, and maintenance. This model works well for projects with well-defined and stable requirements, but can be inflexible and slow to respond to changing requirements.

2. Agile model: The agile model is an iterative and incremental approach to software development, where software is developed in short cycles called sprints. The stages include planning, requirements gathering, design, implementation, testing, and deployment, and the process is repeated in each sprint. This model works well for projects with evolving requirements and a need for flexibility, but can be challenging for teams that are new to agile methodologies.

3. Spiral model: The spiral model is a risk-driven approach to software development, where risks are identified and addressed in each stage of the SDLC. The stages include planning, risk analysis, design, implementation, testing, and deployment, and the process is repeated in a spiral fashion as risks are identified and addressed. This model works well for projects with high levels of complexity and uncertainty, but can be time-consuming and expensive.

4. V model: The V model is a variant of the waterfall model that emphasizes testing and verification throughout the SDLC. The stages include requirements gathering, design, implementation, testing, and maintenance, and the testing process runs in parallel with the development process. This model works well for projects with a strong emphasis on testing and verification, but can be inflexible and slow to respond to changing requirements.

5. DevOps model: The DevOps model is a collaborative approach to software development that emphasizes the integration of development and operations teams. The stages include planning, development, testing, deployment, and monitoring, and the process is highly automated to enable rapid and frequent releases. This model works well for projects with a need for rapid release cycles and a high degree of automation, but can be challenging for teams that are new to DevOps methodologies.

Each of these models has its own strengths and weaknesses, and the choice of model will depend on the specific requirements of the project, the experience and preferences of the team, and the organizational culture. Successful software development requires careful planning, effective communication, and a willingness to adapt to changing requirements and circumstances.

The PfMP Exam is for senior executives who have reached a point in their career where they are part of the council within an organization that decides which projects get funded next. The PfMP is short for Portfolio Management Professional, and is a certification offered by the Project Management Institute (PMI).

Once you've met the criterial for experience and training, you must submit an application detailing your experience, to be reviews by a board of existing PfMP holders at PMI.  This is a challenging process and often applications are rejected.

The rejection letter appears to be somewhat vague, and is actually a standard form-letter. Something a bit confusing is that because it is a rejection form-letter, the reasoning given in it is not always accurate.

What the board is looking for are details of your portfolio (size, types of outcomes, projects, programs), and also what you did to establish the PfMP process, if it did not already exist, and what you do to govern it.  How often you mmet with the portfolio committee, etc.

Portfolio Management is critical within a company because organizations grow through projects.  Project spending actually sets the strategy for a company.

Mike Berry, PMP, CSMC, CSPRO, CSM, CSPO, PBA, ACP, ITIL, CSM, etc.
www.RedRockResearch.com

In August of 2021, PMI released the PMBOK 7th Ediiton.  I have a previous post describing what's new. Surprisingly, is a book filled with professional soft-skills, and not really a process-guide for executing projects.  Wihile PMBOK 1-6 Editions contain step-by-step process guidance for project execution, PMBOK 7 is all about the soft skills.

I tell my PMP and CAPM students they will need both, and an easy way to think about it is to use PMBOK 6 for learning how to manage projects, and PMBOK 7 for learning how to be an excellent project manager.  One analogy I used in a recent public presentation is that PMBOK 6 is the bones, and PMBOK 7 is the meat.

Mike Berry  Red Rock Research

Employee motivation is an ever-present concern for most proactive managers.  Interestingly enough, motivation can come from both functional and dysfunctional sources.

I've seen employees motivated for many different reasons: recognition, financial incentive, empowerment, personal growth, tension release, fear, and finally there's that weird Lord of the Flies thing where employees get motivated together against another employee.

In their book, Motivating Employees, Anne Bruce and James S. Pepitone describe the most effective ways to motivate a team.  They describe the three C's which are vital to functionally motivating employees:

1. Collaboration: Be sure to involve employees in decisions and discussions where their efforts are involved.

2. Content: As they produce suggestions, act on those suggestions immediately.

3. Choice: Be sure to offer choices to your employees--even if you can predict what they will decide.

These three techniques actually empower your employees.   Involving employees in decisions that affect them, or the outcome of what they are working on produces a level of buy-in that is hard to match any other way.

Bruce and Pepitone continue with an examination of Theory-X and Theory-Y motivation and management styles.  These styles were originally presented in the 1960's by Douglas McGregor.

McGregor states that Theory-X managers proceed from the assumption that their employees are uninformed, lazy, and needy of high-structure.

Theory-Y managers, however, proceed from the assumption that their employees are qualified, intelligent, and capable of making proper decisions provided they are given proper goals, accountability, authority, and resources to accomplish their tasks.

Although Theory-X is the most effective approach during some situations, if you consider the amount of college-educated employees in the workforce today, it's easy to see how Theory-Y, if applied properly, yields much higher performance.

The authors continue with a formula for encouraging Entrepreneurial Thinking.   Their five-step formula is:

1. Explain the organization
2. Demonstrate how the organization operates and generates income
3. Help your employees understand the competition
4. Encourage intelligent risk-taking
5. Inspire innovative thinking

Another great idea the authors present is to link motivation to performance.  They suggest you develop a written-list of performance standards for meeting and exceeding the expectations you've agreed upon during collaborative sessions with them.

The authors talk about how important it is to weave fun into everything your organization does.   This may sound like a unusual suggestion at first, but the authors point out that there is a direct correlation between fun on the job and employee productivity, moral, creativity, satisfaction, and most importantly--retention.

The final few chapters in the book discuss de-motivating factors (or individuals), and how to deal with them.  There is also a good chapter on conducting effective employee-reviews.

Overall I recommend this book to any manager.   It's a great book to re-read every so oft r/>
Mike J. Berry
www.RedRockResearch.com

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell's Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.

Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.

Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role. This se to make the most sense to me, and to the others present.

Mike J. Berry www.RedRockResearch.com

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  

Scrum is intentionally quiet about software requirements so that groups can use what works best for them.

In our training seminars, we show groups practicing Agile how they can benefit from a high-level "strategic" use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow components. This technique has proved quick and effective.

Mike J. Berry www.RedRockResearch.com

So I attended our SLC-based agile development forum yesterday.  Alistair Cockburn was there, along with some other associates from around the valley. We discussed various successes and challenges with using the Agile Development Model for software development. 

One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids. Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work.  They gave us some insight on how to proceed. The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions.  They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates.  All of this is measurable, so it works very well with the government procurement types.

Agile is a less structured methodology--where you build requirements and code more in a module, by module format.  These modules, called user-stories, aren't spec'd in detail until they are actually being worked on.  Because of this, milestones and time-lines for an Agile project are not as predictable.  The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.

The trick with the Government is to bid your first project as a waterfall project.  Then, after you have a relationship, suggest that forthcoming projects have an Agile model. You can also submit a Waterfall project with some additional requirements listed on the contract.  ie: "Requirements base-lined at a high-level" or "Progress reported via Project Backlog" or "Prioritization by Need" or "Daily Scrum" or all of these things.

Mike J Berry www.RedRockResearch.com

A curious experience is looking on Microsoft's Project Template website for 'Software Development Project Plan Templates.' 

With Microsoft being a software development company and Project being what it is, you would think there would be many software development templates--some for Waterfall, some for SCRUM, some for XP, some for Crystal, etc. I found only two.  Both were quite rudimentary.  Interestingly enough, though, there are tons of cookie recipes, scrapbook planning templates, and other fun, useful project plans.  I was tempted to add a new subcategory for weekend jeep projects. This sort of begs the question about how many of us are really using Gantt Charts in our software development processes.  I've asked my peers about it and seem to get an overall answer that it takes as much time to update the gantt chart is it does to complete the project.  Hmmm.

We used gantt charts for a while at one of my client sites, in an attempt to display project status.  Although I think the executive staff felt catered to, I got a sort of 'deer in the headlights' effect from them. An interesting side affect was that the development team discovered we could use the gantt chart, projected on the wall in all it's glorious complexity, to underscore how busy our workload was and to negotiate for more time.  (This seemed to momentarily put us in the strongest negotiating position.)

Still searching for a better project status communication medium, I came across a wonderful process called Earned Value Management.  This is a process that developed in the government contractor circles, that displays--all-at-once--the project projected baseline for cost and progress, the actual cost, and the actual progress.  It's a wonderful tool, and after you understand it, you would think why would we do this any other way? Other tools exist, including Agile Burndown (or Burnup) charts--and they are helpful.  They show workload vs. schedule--two of the three series of information.  But Earned Value Charting seems to be the final endpoint for communicating succinctly the progress of your project.

Oh, btw, Microsoft Project will produce an Earned Value Chart for you.  You just need an advanced degree and probably another staff member to keep track of all the numbers it requires.  I wonder if anyone has ever tracked earned value progress on cookies baking in the oven?

Mike J Berry  www.RedRockResearch.com

SQL Server 2005 is fantastic.  SQL Server 2000 was wonderful.  SQL Server 7 was OK.  I hear SQL Server 2008 will be even better...

...but wait a minute??  Really, SQL Server 2000 does everything I need.  So does Oracle versions 6, 7, 8, 9, and 10!  So does PostgreSQL, so does MySQL.  So what gives? Don't get me wrong.  I've grown up in the Microsoft garden.  I still have a VB for DOS development kit, and I have used VB 3, 4, 5, 6, and .NET 2003 and 2005.  These are superb and superior products.  The madness is accumulating with a new release every 2 years.  Microsoft is now forced to offer a downgrade from Vista to XP option because folks are getting fed up.

One client of mine is busy upgrading their flagship product from SQL Server 2000 to SQL Server 2005.  Why?  Not because of any new features.  Not because of a better price.  Not because of really any reason at all, except for the fact their customers are asking for it by name. Because SQL Server (and Oracle) are highly visible in the public's radar, many trade journals speak volumes of marketing info about the new bells and whistles they contain.  As developers, however, we all know that perhaps the management UI is better, and 64-bit it great, but basically the engine worked fine and met all of our needs several versions earlier. So my client is spending $500,000 and seven or eight months upgrading their core product--and all of the internal support tools that must work with it--to SQL 2005.  Again why?  To 'add value to the customer experience'...meaning that the salesperson can say "yes, it works with SQL 2005."

You see, in the real world, often non-technical or semi-technical people make the final purchasing decisions for enterprise software.   They grasp for 'clues' of what should separate an inferior product from a superior product, and--well--version 2005 should be better than 2000, right?  Therefore, a product based on 2005 is better than a product based on 2000!  Right?  In reality, somebody must pay for the $500,000 so that same customer is misleading themselves into requesting a higher price-point.

A better model would be to choose a database that is solid, but not in the customer's radar.  This way, they would have no 'journal information' about the database and would not be pressuring you to spend $500,000 every other year to keep up with Microsoft. PostgreSQL, MySQL, Interbase, etc. are all robust databases with 64-bit support now.  If your software is for an internal client (your own company), this whole dynamic shouldn't affect you, but if you make a commercial client-server product, there's no doubt you've experienced this already.

Mike J Berry www.RedRockResearch.com