Software Engineering and Software Development as a Craft

What is the difference between software engineering and software development as a craft? Which is “right”?

Software engineering and software development are interrelated terms, in which a software engineer is involved in software development; however, not all software developers are engineers. Software engineers apply engineering concepts in software creation. They participate in software development in software development life cycle through customer needs with applicable technological solutions. Software engineers systematically development processes to provide specific functions. They engage in software process by requirement gathering and analyzing, creating system architecture, software development and coding, Troubleshooting, Deployment, Following up, Handling hardware and networking, testing etc.(“Software Development Craft vs. Engineering.pdf,” n.d.).

Software developers are performing a creative force behind software programs. They engage in building the entire development process. The majority of the software program creation is carried out by software developers. So, they must have excellent analytical skills as they will be required to continually compare needs with software capabilities.


After considering the main tasks and skills of software engineers and software developers, my point of view is neither the work done by software engineer or a software developer, can consider as a craft, because both groups engage in creation, development and analysis. After a long term engagement of the same process, software development can be a craft.

What is the culture of an organization that agile testing works well in? What kind of organization will it not work well in?

Agile testing is a practice of testing software for bugs or performance issues within the Agile workflow. When consider the culture of an organization that agile testing works well, collaboration culture comes first. Agile developers work closely together, favoring direct communication, rather than passing documents back and forth to each other. If team work and cooperation lead in a particular organization, Agile testing works for them. Due to the grater collaboration and adaption of test-driven development approaches in Agile testing, the work cycle of the software process would be shorter.

Secondly, Agile testing requires far greater discipline than traditional testing methods. For an example, Agile testers should work closely with stakeholders, respect their decisions, produce quality software products on a regular basis, and write a single test before writing just enough production code and so on. So, maintaining a greater flexibility and discipline within an organization is important in order to survive in Agile environment.

Furthermore, greater range of skills are required to get adapt to Agile environment. It is not enough to be just a tester, or just a programmer or just an analyst. Agilists should be more over specialized in order to move toward highly iterative and collaborative approach.(Ashmore & Runyan, 2014).

On the other hand, some organizations are not suitable to get adapt in to Agile environment. Following are some features of an organization in which the Agile doesn’t work:

  • Atmosphere and culture of the organization are not collaborative
  • Tester involvement is far behind the development process
  • Maintenance of two different departments for software development and quality assurance. In Agile environment, there is not a separate QA department.

Should the QA team work for the software development manager or for a QA manager? Why??

QA team may be a separate team in an organization, but it is a part of the software project team. QA team is involved in the project from the beginning, and the whole team works together to evaluate or establish processes, set up measurement programs to evaluate processes, and identify weaknesses in those processes, to produce a quality product. My opinion is QA team should work for both software development manager and for a QA manager. I will point out the reasons for that.

Quality assurance managers supervise the QA team who carries out the detailed assessment of products and their components at different stages of production. Therefore, QA team should definitely work for QA manager.(Katz, n.d.)

Furthermore, QA team is empowered to support projects and add values to the projects in many ways such as design reviews, requirements assessments, browser and device support, process, tools, risk assessments etc. QA team sits with the project team whenever possible, allowing for increased conversation and problem solving in real time. Therefore, the QA team directly engage with the software development process and they should work for software development manager as well.

What kind of metrics does an agile QA team need to keep?

Agile QA teams usually use metrics to measure their software systems and evaluate their performance, so they will flex their efforts to improve the quality of the product. Following are some of the metrics that agile QA team need to keep.(“Agile development teams should decide which metrics are most useful,” n.d.)

  • Sprint burndown – Agile teams organize their development into time-boxed sprints. This report forecasts how much work they can complete during a sprint.
  • Velocity – It is the average amount of work a development team completes during a sprint, which is very useful for forecasting. The report can tracks the forecasted and completed work over several iterations.
  • Control chart – This focuses on cycle time, the total time from when a story moves from To Do into In Progress to the time it’s Done. Measuring cycle time is an efficient and flexible way to improve a team’s processes and it allows them to make any further adjustments right away.
  • Cumulative flow diagram – This allows the team to ensure the flow of work across the team is consistent.
  • Defect density – The number of bugs discovered during a sprint. This measurement is a call back to the team’s commitment to quality. The lower the number of bugs the better.

What’s the difference between a testing strategy & test planning?

Testing Strategy

  • Usually developed by project manager.
  • Test strategy is a set of guidelines that explains test design and determines how testing needs to be done.
  • Main components are objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, etc.
  • It is a long-term plan of action, which stands for testing processes and activities.
  • It is a static document which is not update too often. It can’t be changed.

Test planning

  • Normally prepared by test lead or test manager.
  • Testing plan is a document that defines the scope, objective, approach and emphasis on a software testing effort.
  • Main components are features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and schedule, etc.
  • Test planning is done to determine possible issues and dependencies in order to identify the risks.
  • It can update more often to reflect any deviation from original plan.